Models are made up of objects, relations and attributes.  All user interaction in LiveModel works with these things.  Linking a task with a subprocess adds a relation.  Editing a description changes an attribute and so on.  This is all very clean and simple.  And then there are diagrams.  Diagrams present a challenge because unlike working in the hierarchy or on a single object in the details pane, multiple changes can be made that widely affect a model.  New objects can be created.  Relations can be formed and broken.  The job of keeping the model 'in-sync' falls to the infamously titled DHReconciler (or Diagram Hierarchy Reconciler).

The reconciler's job is to ensure that the presentation of the model - in the form of the hierarchy and diagrams - accurately reflects the state of the model as stored in the database.  If a task is linked to a subprocess it must show up in the hierarchy and on the subprocess' diagrams.

LiveModel 2.0 introduced a new modelling tool called the Cross-functional Flow Diagram (CFD).  The CFD is a combination of the Flow and Swimlane diagram types.  The one concrete example of the CFD is at the subprocess level.  Roles are used to define lanes and Tasks are the active lane elements.  By active I mean when a task shows up in a role lane then it represents a real relationship between the task and role in the model.

The CFD is editable.  You can add a task to a lane.  Delete a task from a lane.  Move a task between lanes.  When the diagram is saved the DHReconciler updates the model to reflect any changes made.

Customer feedback has prompted us to look at whether the strict enforcement of the reconciliation works best for this diagram type.  Consider this example.  You have a task that's related to two roles.  The task is also used in two subprocesses.  Should both roles be displayed in each of the subprocess CFDs?  It seems the answer is not yes but maybe.  With the reconciliation process we have today the answer is always yes.

To resolve this we're going to add a second reconciliation policy just for CFDs.  This policy will be activated by changing a server-side configuration setting.  When active the following rules will apply when saving a CFD:

1. Adding a task to a role will create a relation between the task and role in the model.
2. Deleting a task from a role will not delete the relation between the task and role in the model.
3. Moving a task between lanes will be a combination of (2) and (1) above.

If the hierarchy - via drag 'n' relate - or the Object Linking Wizard (OLW) tool is used to create/delete task/role relations then the following rules will apply:

1. Adding a task/role relation will not update any CFDs.
2. Deleteing a task/role relation will move task nodes in affected CFDs out of the role lane.

In short, this new reconciliation policy will ensure that while the CFD may show less information than is in the model (not all roles may be visible in a CFD) it will never show more information than exists in the model.