Hello Experts,
We have an identity attribute called Entity. Whenever this attribute changes, a few dependent attributes of an application also change which need to be provisioned to the target system.
Currently we have added 10+ attributes for the same application in target mapping for that identity attribute with their own transformation rule.
Could you please suggest the best practice approach for handling such dependency-based attribute changes?
Thanks,
Shamal
There are 15 fields dependent on the ‘Entity’ attribute value change which we need to push to target system with some data transformation. Currently we have defined 15 such data transformation rule attached to the target mapping. However, thinking if this is the best option or should we leverage the beforeops rule to do the calculation of all dependent attribute and just have one transformation rule attached to the ‘entity’ attribute change trigger target mapping
Thanks,
Shamal
this sounds like an Lifecycle event base requirement, I would do this in a custom workflow which will handle the logic calculation for the 15 fields for each applications in a provisionPlan.
example:
Create an event called EntityChanges of type Attribute change. Point the your “entity” attribute for changes and add your custom workflow.
That should take care of provisioning to these fields in a best practice approach.
Try handling this using LCE and you can give trigger condition as attribute based changes where you can put “Entity”.
Create a custom wf and call it
Inside wf create plan and execute it.
if you want request generation then use OOTB LCM and update one of your steps to create plan
Hi @shamal_khokle ,
as per my understanding you are describing the following situation:
You have an identity attribute and numerous target system (schema) attributes which should be updated as soon as the identity attribute changes.
Can you please confirm or correct.
If my understanding is correct the “Attribute Synchronization” feature is you friend which does exactly what you describe.
As soon as the “source”/identity attribute changes, it will push those changes into the relevant target systems as defined within the ObjectConfig “Identity”.
You can check this article and please also have a look into the documentation:
Attribute synchronization enhancements in IdentityIQ 8.2 - Compass
Best regards,
Daniel
I would suggest you create a Value Change Workflow and add your logic to change all the other 15 attributes by building a provisioning plan.
15 dependent fields is unusual, but if that is what you need then it should work ok.
Hi @shamal_khokle ,
This requirement can be achieved by “Value change Rule” also.
You can monitor performance and decide which option is suitable.
@shamal_khokle - If you only need to provision the new value, then having 10-15 target mappings is the best solution. If you need to perfom additional steps whenever the value changes, you can create a lifecycle event or have a value change workflow in the identity mappings.
@shamal_khokle You need to understand the tradeoffs. If your Target Mappings are working fine, then you can continue with it. If you face any issues like identity deadlock, refresh taking longer, etc., then you can think of other options like Lifecycle Events, where you refresh task can launch the workflow and move on to next identity.
Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(
,
, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
First things first. You should not create an Identity Attribute that starts with a capital letter. All Identity Attributes should be either all lower case or camelCase. No underbars, no numbers, no repeated caps. No “ID”. That’s why the example is costCenter. You should have called it entity if anything, although entity seems like it is not a likely name for an identity attribute. An Identity IS an Entity, it wouldn’t have an entity attribute.
Next, to specifically answer your question, you can add as many target outputs as you want, and can do multiple outputs to the same target if you want. I have worked on clients where they had dozens of targets to write back, with multiple transformation rules. Each target write creates an AttributeRequest on an AccountRequest on the target application, which are then compiled and executed.
Don’t do a value change rule that’s old school and hard to control.
Don’t do a custom workflow that’s overkill. Just write your 15 transformation rules and load it up.
