The simplest way to explain the best strategy is to consider the simplest standard sync server configuration, with just two management agents (MAs) ... HR and AD (single domain).  In order to simplify the discussion, I will limit "part 1" to just the sync server, with all provisioning rules done in traditional rules extensions (no declarative portal sync rules at this stage)

Lets assume we have the following setup:

• HR (SQL database) - FIM Metaverse - Active Directory
• HR is authoritative for the data, which needs to land up in AD

Question

What do we need in the way of 'import', 'sync' and 'export' run profiles between HR and FIM MV, and between FIM MV and AD?

Answer

Define the following run profiles for your 2 MAs ...

 Run Profiles for our HR MA:

• Full Import + Full Synchronization ... used for initial load and subsequent re-baselines only (suggest provisioning is disabled for the initial load, and enabled after all joins are done - see below)
• Full Import + Delta Synchronization ... used for ongoing import/sync runs to get the latest authoritative HR data (presuming you don't have a Delta Import capability)
  ... OR ...
  Delta Import + Delta Synchronization ... used for ongoing when you have a mechanism in place (triggers/sql views/etc) which make the need for continuous full imports redundant
• Export (but ONLY if you want to flow attributes back to HR ... reading here that you don't)

Run Profiles for our AD MA:

• Full Import + Full Synchronization
• Export
• Delta import + Delta Synchronization

Projection/Join Approach

A common implementation approach with the 2 MA scenario above is to project only from the "authoritative source" for the identity, namely the HR MA.  This way the AD CS objects are only ever joined to existing MV objects and remain disconnectors if no join occurs.  The idea here is that you can be confident that your metaverse only ever has an object for every HR employee record, provided you disconnect the AD connector in the event that an HR connector is ever deleted.  This assumes that accounts are never created directly in AD again once provisioning is enabled ... to avoid the "cs object already exists" provisioning exception that can ensue.

A good way of avoiding the above exception is to project onto the MV from BOTH MAs, and using a secondary indexed metaverse attribute to achieve joins that will prevent the creation of duplicate metaverse objects.  An example of this is where your first join rule for both AD and HR MAs is on employeeID in the metaverse, and the second is on accountName in the metaverse.  Let's suppose you can "breadcrumb" your HR system with the sAMAccountName from AD in much the same way as you store the HR employee ID in the AD employeeID attribute.  Under these conditions, when an HR employee record is created AFTER an account for that employee was created in AD, a join can still be established from HR in lieu of a new metaverse object being projected.  With a bit of careful AD/HR operational cooperation this can avoid sync exceptions in the common scenario where there is a need to have an AD account created in advance of HR setting up the personnel details in HR.

For the ensuing documentation, the assumption is that you have adopted this second approach ... however I acknowledge that there may be circumstances where the first approach is the only sensible option. 

Initial Load/Re-baseline run profile sequence

The first time you load the 2 MA connector spaces and project/join to the metaverse, disable provisioning to ensure joins can be established and anomolies resolved.  Thereafter use this sequence for

• AD - Full Import + Full Sync (least authoritative first - minimises re-processing)
• HR - Full Import + Full Sync
• AD - Export
• AD - Delta Import + Delta Sync

* Note that the above assumes you are projecting from BOTH AD and HR MAs as outlined above - otherwise the HR full import must run first before AD to allow joins to occur.

Ongoing (delta) run profile sequence

If you don't have something like Event Broker to run these automatically on demand, you will need to schedule the following sequence - at a frequency based on your operational requirements and the allowable latency threshold for your solution:

• AD - Delta Import + Delta Sync
• HR - Full Import + Delta Sync
• AD - Export
• (HR - Export)
• AD - Delta Import + Delta Sync
• (HR - Full Import + Delta Sync)

When to run a full import rather than a delta import

When using a management agent (such as the AD MA) that supports delta imports, you must still run a full import in several scenarios including:

• Initial load of the connector space, as described above.
• The data source's schema changes.  In this case, first refresh the schema for the management agent, and then run a full import.
• The attributes included in the MA properties are changed.
• In a disaster recovery scenario after restoring from a backup. 
• To pick up changes that were missed in a delta import, for example a SQL MA could have a delta view configured but in some circumstances not all changes are included in the view.

When to run a full synchronization rather than a delta synchronization

A full synchronization is needed when the rules that apply to connectors are changed.  Such changes could be made in:

• Filters
• Attribute flows, including import and export, direct and advanced
• Metaverse provisioning code
• Additionally, any classic rule extensions that use the current date to make a decision (comparing with a termination date, for example) would require the scheduling of regular full synchronizations.  Delta synchronizations only process changed data, and the passage of time does not trigger a delta sync evaluation of a time-dependent rule.  (The use of temporal sets in the FIM portal would eliminate this need, but that is outside the scope of this article.)

Join and projection rules only apply to disconnectors, and if changed a full synchronization is not required to make them take effect.  A delta sync (not combined with a delta import in the same step) would process all of the disconnectors in a management agent's connector space and apply the join and projection rules.

Note that when running a delta-type run profile for a management agent, FIM will provide warnings either via pop-up window (if initiating the run manually via the GUI) and/or events in the application log if it notices that any configuration point has changed and a full synchronization has not yet been run on that management agent since the change.  Such changes include any made to any MA's properties and any changes in the Extensions folder (a good reason never to write a log file to that location).  In some cases, the warning can be ignored.  In others, a full sync may be indicated on a particular management agent (one with a new or newly modified import rule, for example), but warnings for delta syncs run on the other MAs could be safely ignored. 

For Parts 2, 3, etc. we can look to build on this basic concept.  This will include adjusting the run profile sequencing to support declarative sync rules configured in the FIM portal ...