Cloud rule for Identity Attribute is returning null value

Hi Team,

Please somebody check on the error on below cloud rule as we were trying to map IDN attribute of BU_ID with EBS Source attribute BU_ID value Keeping Cost_Center_Code as Account ID in Schema.

<Source><![CDATA[
	String EBS_SOURCE="EBS [source]";
	String  costCenterCode = null;
	costCenterCode = identity.getAttribute("costCenterCode");
	if(idn.getAccountByNativeIdentity(EBS_SOURCE,costCenterCode)){
  		String attrValue = idn.getAccountAttribute(EBS_SOURCE, costCenterCode,"BU_ID");
		return attrValue;
	}
	else
		return null;
  ]]>

Are you using the Rule Development Tool Kit for this rule?

1 Like

I’m not sure, we’re providing this to SailPoint Support Team to deploy the rule in IdentityNow.

Is this on a new identity?
You’re using an Identity attribute in your rule… this is considered bad practice since the attribute might not yet be populated during your rule run, causing costCenterCode to be null and not triggering your code.
What you typically want to do is pass the costCenterCode to the rule (mapped straight from the original source) through a transform.
Then you can use the value of the original source.

But honestly, seems like you can do everything in this rule through a transform already and have no need for a rule…
Use the account attribute transform

Hi Remi,

We tried to achieve this using Transform it didn’t work as all the identities from EBS are uncorrelated. There’s two sources- one is EBS and another, we need to manipulate BU_ID value from EBS based on Cost Center Code and map to Identity Profile of another source.

EBS is not an authoritative source.

To save yourself time I would highly recommend installing and using the Cloud Rule Development Tool Kit or Opening an Expert Services Ticket to have them help in building out the rule. This will lower the time spent going back in forth with deploying the rule. The tool kit allows you to test your code before deploying it to your tenant.

Hi @asriva14 ,

As mentioned by @tysremi , try to use the account attribute transform as it is quite easier to test and will reduce the dependency on rule deployment