none
Best Practice Question: Portal Sync Rules RRS feed

  • Question

  • Hi,

    Is there any benefit in combining Inbound and Outbound Flows in a single Sync Rule?

    Or does it not matter if Inbound flows have their own Sync Rule and Outbound flows have their own Sync Rules?

    Does either option generate more/less EREs/DREs?

    Is either option better for performance reasons?

    look forward to your comments, thank you

    sk

    Friday, March 28, 2014 2:41 AM

Answers


  • Sometimes splitting out OSR's for the sake of logic and ease of management can be helpful. It's easier to look at the SR for an inactive user than it is to update a giant nested IIF custom expression (and it's much easier to make errors in those). 

    In your situation I would keep the separate SR's , the user should only have one of these active at a time, so realistically only 1 ERE. Assuming you are removing the other 2 SR's when they transition into their "current state" set. 

    • Marked as answer by Shim Kwan Friday, March 28, 2014 8:20 PM
    Friday, March 28, 2014 7:30 AM

All replies

  • ERE's are only generated by OSR's applied by synchronization triples (Set, MPR, WF). DRE's are only generated when you check the existence test option within the SR. ISR's are applied automatically. The only benefit I can see by separating your OSR's and ISR's are the ability to apply different join rules to the same object type.  So I can't see why combining them should cause any performance hits, as your number of EREs/DREs should stay the same. 

    Not sure if there is a best practice for this, but I generally combine them for convenience. I think this one just comes down to personal preference and how you want to manage your environment. 

    I also prefer to use import flows to a boolean attribute rather than DRE's, but that's just me. 

    Friday, March 28, 2014 3:08 AM
  • Thanks Cameron -

    Question 1:

    Just came across an environment where 7 Sync Rules (inbound & outbound) are doing what 1 Sync Rule can do...just was wondering if this 7 would create more EREs than a single Sync Rule.

    Question 2:

    With your import boolean method: do you do a check using something like 'IsPresent' to detect if an attribute already exists, and act based on the TRUE or FALSE result - Thus not having any DREs?

    Friday, March 28, 2014 3:22 AM
  • 1:

    Only the OSR's create EREs, so if you have 4 outbound 3 inbound (assuming a user gets all 4 outbound SR's) the user should have 4 EREs. If the rules were combined into 3 outbound/inbound and 1 outbound, the user still gets 4 EREs.

    2:

    If my source was AD, I would create a new MV attribute called inAD. Then import a constant "true" from the target, AD for example. Then from my source, HR for example,  ill flow in a constant "false". Lastly update the MV attribute precedence for the inAD attribute to be AD then HR. From there i'd create a custom attribute in the portal so I can use the flag for set criteria.

    This might be a long winded way of getting it done, but say you have 10k users in AD and used DRE's. It means 10k more objects in the MV and in the portal. 

    Disclaimer: Not saying this is best practice, it's just what I do :) 

    Friday, March 28, 2014 3:43 AM
  • Thanks, let me see if I understand.

    Assume we have 3 outbound AD sync rules: 1 for active users, 1 for inactive users, 1 for users that have left the company.

    What if I were to combine this logic into 1 outbound AD sync rule?

    How would this affect the number of EREs associated with a user?

    • Edited by Shim Kwan Friday, March 28, 2014 7:14 AM
    Friday, March 28, 2014 7:13 AM

  • Sometimes splitting out OSR's for the sake of logic and ease of management can be helpful. It's easier to look at the SR for an inactive user than it is to update a giant nested IIF custom expression (and it's much easier to make errors in those). 

    In your situation I would keep the separate SR's , the user should only have one of these active at a time, so realistically only 1 ERE. Assuming you are removing the other 2 SR's when they transition into their "current state" set. 

    • Marked as answer by Shim Kwan Friday, March 28, 2014 8:20 PM
    Friday, March 28, 2014 7:30 AM
  • thanks Cameron, things are clearer now.
    Friday, March 28, 2014 8:20 PM