8.2
Hi,
I wanted to know is there any way to clear out Telephonenumber and mobile attribute of AD based on data coming from Successfactors. Basically if business mobile and business telephone are empty in Successfactors then the AD attribute Telephonenumber and mobile should also be cleared out on refresh so that everything is in Sync.
Is there any way
Try below transformation rule
String returnValue = link.getAttribute("mobile");
if ( null == returnValue )
{
returnValue = "";
}
return returnValue;
Is this be placed in target attribute under identity attributes?
So actually we have rules doing that for SF attribute in indentity attributes and same is set to be in sync in target attribute as AD attribute but in AD its not syncing.
This is what attribute sync is for. Define a new identity attribute called businessMobile and a second called businessTelephone, and have them sourced from those fields in Successfactors. Then put telephoneNumber and mobile as targets, respectively. Just make sure that your synchronize attributes is checked on the identity refresh task.
Most of the time the complaint is “I lost the value from the source and I want to retain the last value I had, don’t clear it out”
Yes we have that kind of setup already. Now for one user his telephone was cleared out long time ago in Successfactors but in AD it is still there so needed to clear it out but that is not happeningg
did you try the rule shared ?
you need to try this rule in transformation rule , also add required mapping
I have seen this before. You’ll want to troubleshoot this.
First, make sure that if you change a configuration, that you rolling restart all of your task servers. Next, verify the connections in the Identity Attributes, verify the Source and Target. Also verify that the identity attribute is set to read only. Any form of edit-able - temp or perm, will disrupt attribute sync in one way or the other.
Next check the values in the 3 places: the source, the identity attribute, and the target. What you are looking for is for the value to be null (or missing) in the source, for it to be present in the identity attribute, and present in the target. That will be the starting point for the refresh operation: the source has cleared the value so the refresh should clear it both in the identity attribute and then in the target.
Next, just run a single identity refresh. Create a new identity refresh task and call it something like xyz Identity Refresh Single and then put name==“identity” where identity is the identity name of the user. Make sure that the refresh identity attributes and the synchronize attributes are both checked, and run the single refresh. Look at the provisioning operations - should be more than zero.
Final check is to go to the Administrator console, to the Provisioning link, and look to see if you are saving Successful provisioning operations. If not, you might turn them on for a bit, in the Gear Icon - IdentityIQ settings - Misc right side change Fail to Success. Look for an AD provisioning operation on that user and if see if it was successful or a failure. Possibly something else failing, might have failed everything.
Last thing to check is the IQService logs.
You should see the identity attribute update and then a provisioning operation on AD that should be successful and then see the data cleared out.
Hi,
I tried running the refresh on single user we got only identities examined and identity entitlements updated in the result.
Also everything is already checked in the task
@Amsingh1 Pls check You add transformation rule and target mapping for these attribute as Vishal suggested.
In refresh you need to add Sync attribute options.
Your message is unclear, did the attributes update on the target? Did you go through all of my troubleshooting steps?
I haven’t ever seen a need for a transformation rule like this, but I will test this in my local and if it’s needed I will update and stand corrected.
I just ran this against both Active Directory and against an OpenLDAP client, clearing out the value in the source and then refreshing the user clears out the data in the target. Here’s the proof from the Administrator Console. There’s no need for a transformation rule.
@vishal_kejriwal1 Please see my note at the end, no transformation rule is needed. If there’s an issue that’s not it.
For the user i am checking there is one modify transaction in that the telephone attribute is not included although everything is setup in identity mappings
One more question let say on Active directory someone manually added the phone number but we are not ggetting the attribute from SF then in next refresh will that atrribute will be overwritten i.e. gets cleared or there needs to be some custom rule written for this.
That’s what I was mentioning about editMode. For synch to work properly it needs to be set to read only. If it is set to permanent then it will always have to be hand edited once it is touched manually. The temporary setting means it won’t synch unless the source value changes.
yes it is read only
so you mean that if the AD side was updated manually then it should be cleared manually only because source will remain as it is. Right?. Also if we want that the value should be updated in each refresh even if the source is not getting updated so can that be achieved.
Kind of lost me there. Look at your Administrator Console - Provisioning and look for that user, that connector.
Make sure that you see successful provisioning operations:
If not go to global settings, IdentityIQ Configuration, Misc tab and set to Success
Refresh the user and then look for the provisioning operation:
What are you seeing?
I have done my own testing and there’s no scenario that attribute sync is foiled by other actions. I tried both editMode values and once set back to ReadOnly, the functionality returned. I set the value on the AD target using ADUC and IIQ restored the correct value; however the only way that IIQ knows that the value has changed on AD is after an aggregation. You need to figure out why the Identity Attribute is not being updated, which appears to be your main issue. Have you verified that the source value has changed?
