I would just like to have some input if someone has some experiences around this. Declarative is nice and easy but I think it is limiting and even with relatively easy deployments you could get stuck with the functionality. Hybrid uses Declarative until the function is not available, then uses classic rules to code the rest. Although this is most likely the best of both world I am not too fond about running this model as there are rules declared in the Portal and other in the Sync Engine.Classic. Although it is all coding from here it is relatively easy to understand. Although you will be coding everything. If I read the comments out there they are using old school Classic rules or Hybrid and seems like a personal preference. Let me know want you guys think.

I'm glad to share my opinion. This is my general thought process, and what I teach in the Oxford FIM Experts course (shameless plug for our training :) Conceptually, I break functionality between the portal and sync service this way.. Policy is defined in the portalExecution of the policy is performed in the sync service If you think about what the ERE model does - It transports provisioning information between the portal and the sync engine with a custom resource type containing provisioning information. Although it mostly works as designed, I'm not a big fan of this method (whole other discussion). Instead of moving custom objects around, my approach is to add additional attributes to the person object for provisioning, such as which entitlements the user will get (i.e. an AD account, Mailbox etc.) The calculation of which entitlements is done in the portal, where the business logic behind these decisions is easily visible and updatable in a decently accessible fashion to non-coders. This is especially handy if the criteria for getting certain entitlements is subject to change (and in some cases changes frequently) Once I get all this decision making done in the portal, I populate my provisioning attributes and use some very simple, generic and reusable classic code to implement those policies in the sync server. If you're doing any non-trivial implementation you are going to need some custom code anyways, so forget about the 'no-code' marketing-speak. This becomes more important as a consulting architect - when you're designing an architecture to be implemented by multiple consultants for lots of customers. the more you can reuse concepts (and actual code) the easier it is for someone to walk up to an implementation and get up to speed on how things are designed. There are times for various reasons that you may deviate from a 'pure play' implementation, but such is the reality of the strange and varied world of IT, but so far, this model has worked well. Frank C. Drewes III - Architect - Oxford Computer Group

Thanks for your view on this. This makes more sense than trying to use some declarative rules for some sync rule attribute flows and classic rule for the rest.