ServiceNow Correlation is not working

Hi All,

I was working on the ServiceNow integration with sailpoint. i did the configuration and that working fine. While Aggregating the user’s data correlation is not working it’s ignoring the accounts. below is the correlating code.

import sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;

Map map= new HashMap();

String empid= account.getAttribute(“Employee number”);

if(empid !=null &&!empid.isEmpty()){
map.put(“identityAttributeName”,“employeeId”);
map.put(“identityAttributeValue”, empid);
}
return map;

The correlation rule looks syntactically correct. I would first verify that Employee number is the actual schema attribute name (not just the display label) and that employeeId is the correct identity attribute in IdentityIQ. Also confirm both attributes contain matching values. If those are correct, enabling debug logging in the correlation rule to print the retrieved empid value would help determine whether the rule is receiving the expected data during aggregation.

You can print/enable the logs to validate if the account attribute value is matching with Identity attribute (employeeId)

Hello Shubham , the issue might be the attribute name in account.getAttribute("Employee number"). In ServiceNow’s sys_user table, “Employee number” is the column label, but the actual field name is employee_number (underscore, lowercase). IIQ needs the exact schema attribute name. Because of this mismatch, empid comes back null, the if block gets skipped, and IIQ sees no match. Check your ServiceNow application’s Account Schema in IIQ to confirm, and update your rule:

String empid = account.getAttribute("employee_number");

Also make sure employeeId is the exact identity attribute name on the identity cube and is searchable, otherwise correlation fails silently. After updating, run aggregation with “Disable optimization of unchanged accounts” checked so IIQ re-evaluates all accounts with the new rule.

Hi @Gutte_Shubham ,

Check if the “Employee number” attribute is correct and added to the application schema, and if empid is getting populated or not using logs or print statement.

your map key is wrong. The Correlation Rule must return "identityAttribute", not "identityAttributeName" — that’s why every account is being skipped (IIQ doesn’t recognize the key, so no correlation criteria gets applied).

java

import sailpoint.object.Identity;
import java.util.HashMap;
import java.util.Map;

Map map = new HashMap();
String empid = account.getAttribute("Employee number");

if (empid != null && !empid.isEmpty()) {
    map.put("identityAttribute", "employeeId");
    map.put("identityAttributeValue", empid);
}

return map;

Hello Naveen, I checked the correlation rule documentation, and it shows identityAttributeName and identityAttributeValue as the expected return-map keys. It looks like identityAttributeName is correct for this correlation method. Switching to “identityAttribute” might actually cause issues.

Can you confirm account.getAttribute("Employee number") is actually returning a value? Adding a few debug logs in the rule can help verify this.

Hello All,

Thank you for your responses. Sorry for the delay in the response back.

HI @punna0001 ,

There is an attribute mismatch in the rule this is employee_number is the ServiceNow schema Account attribute i have fixed the code. employeeId is the identity custom attribute and that is searchable. I have attached snapshot for the same. Both attribute value is same.Upon all the fixes still the rule is ignoring the account correlations. in the loge file also don’t see any informaiton.


image
image

If correlation is still not working and nothing in the logs, I think the rule is probably not getting executed.

First, confirm ServiceNow_CorrelationRule is selected under your ServiceNow application’s Rules tab. If it’s not assigned to the application, IIQ won’t run it.

Also, since this is a straightforward employee_number to employeeId match, you can actually skip the rule entirely and configure it directly under the application’s Correlation tab as an attribute-based correlation. That’s simpler and easier to troubleshoot.

Either way, rerun aggregation with “Disable optimization of unchanged accounts” checked, otherwise IIQ will skip these accounts since they were already aggregated before. If the task still shows Ignore, check whether “Only create links if they can be correlated to an existing identity” is enabled on the aggregation task, because IIQ reports Ignore when no matching identity is found and that option is on.

@Gutte_Shubham It looks like you don’t need a rule. you can create a correlation config with employee_number as app attribute and map it with employeeId attribute. Any specific reason you want to have it via correlation rule?