Creating a Custom Attribute Using Source Mapping Rule

This post will show the basic steps on how to create a new attribute based off certain criteria that is onboarded from a delimited file, like an employee or contractor feed.

While the steps below show a fairly simple method, and while there could be several more complex scenarios and solutions that may apply, this is how you would create such an attribute without having to modify the delimited file structure.

The Scenario

I will be demonstrating a scenario where a company has 2 out-of-state locations based in Clearwater and Tampa, FL. If one of the employees has their location listed as either of those two cities, we will display an attribute “Florida Residency” to read as “Resident”. If they do not have either of those listed, it will display “Non-resident”. The advantage to something like this would be if you wanted to base access off of the newly created attribute, for example Florida Residents may need VPN access or access to a travel app that can be provisioned later.

The Steps

  1. Add attribute in Identity Mappings
  2. Configure UI to display the attribute
  3. Edit attribute’s source mappings
  4. Test

Add Attribute in Identity Mappings

Location: Gear > Global Settings > Identity Mappings
Scroll to the bottom of the page and hit the button “Add New Attribute”
Name: flResidency
Display Name: Florida Residency
Attribute type: String
Edit Mode: Read Only
Searchable: Checked
Group Factory: Checked

Hit the save button.

(We’ll come back to this page in a few steps.)

Configure the UI to display the attribute

Go to the Debug Pages (host:port/identityiq/debug/debug.jsf)

In the select an object field, type in UIConfig. Click on the result when it comes up.

Search for a line that looks like:
<entry key=”identityViewAttributes” value=”name, firstname,lastname,email,manager…. etc etc

Somewhere within that line, you will need to put in the Name of the attribute you just created. In my case, I will be using flResidency.

Save the page.

Next, we’ll confirm that what we just defined is all set.

Navigate to Identities > Identity Warehouse. Click on any user. You should now see the Display Name (in my case, Florida Residency) you used for the attribute appear somewhere in the user’s Cube.

Edit the attribute’s source mappings

This is where the fun happens and is where we will create our rule.

Go back to the Identity Mappings page (Gear > Global Settings > Identity Mappings) and go to the attribute you created.

Scroll down to Source Mappings, and click the “Add Source” button.
In the pop up window, select Application Rule. Select the application you’ll be aggregating from. (In my case, I’m aggregating from the Contractor Feed and from the HR System – Employees feed, so I’ll be doing this step twice.) Next to the Select Rule field, click on the “…” button. This will bring up the rule editor pop up. On the right, give your rule a name. On the left, enter the following code (you can ignore the “//” lines):

//we’ll be gathering accounts and their attributes
import sailpoint.object.Link;
import sailpoint.object.Attributes;

//here is the name of my attribute
String flResidency;

//if the user’s location is Tampa or Clearwater
if (link.getAttribute(“location”).equals(“Tampa”)) {
flResidency = “Resident”;

else if (link.getAttribute(“location”).equals(“Clearwater”)) {
flResidency = “Resident”;

//if they’re not in either of those cities…

else {
flResidency = “Non-Resident”;

//Sailpoint always needs a return
return flResidency;

Save your rule.

After the window closes, make sure to select the rule you just created. Click Add. You should now see the your application and rule you’re using in the Source Mappings for your attribute now. If you have any other applications you’re basing this off of, you’ll need to repeat this step, using the same rule, but choosing a different application.

Scroll down to the bottom and save your attribute.


We will now need to test what we just implemented.

Run the aggregation task associated with your application (in my case, the employee and contractor feeds). After aggregation is completed, navigate to Identities > Identity Warehouse and select an identity. You should see your users listed as either a Resident or a Non-Resident. To double check and make sure it has worked, navigate to a user whose location is known to be Tampa or Clearwater, and observe Florida Residency to read “Resident”.

If any entitlements are based off of your new attribute, now would be the time to run a refresh.

Additional Notes

This demonstrates creating a custom attribute on a very basic level. There are other ways to implement this, and there are many other java methods that could be used to structure your results. This rule could also be called via a global mapping rule. Always remember to create something like this in your dev environment, and run in test before implementing this into a prod environment.