Introduction

While provisioning accounts with HelloID, you may want to leverage information from one target system in another target system. For example, you may want your users' Active Directory usernames to be used in their Google Workspace email address. This is done by marking target system attributes to be stored in Person records, or exporting them in the case of a custom PowerShell system.

Important: Do not make two systems dependent on each other. This creates failure and/or race conditions during enforcements.

Store attributes in a person record

Before you can leverage attributes from one target system in another, you must choose which attributes to store for later use. Here, we will show you how to do this in both a simple target system, and a custom PowerShell system.

Simple target system

Within a simple target system (e.g., Active Directory), making attributes available to other systems is as easy as toggling a switch. Edit the target system of choice, and navigate to the Account tab. Then, find the attribute that you wish to make available and enable the Store this field in person account data setting.

When you are finished marking attributes, click the Apply button to apply your changes. Then, click the Force Update Accounts button. This will cause HelloID to update the target accounts as necessary, and pull the marked attributes into Person records for later use by other target systems.

Custom PowerShell target system

Just like a simple target system, you can export account data from a custom PowerShell target system. In this case, however, it must be done in the code of your Account Create lifecycle stage.

Edit the PowerShell target system of your choice, and navigate to its Account tab. Once there, click on the Configure button for the Account Create stage, as seen below.

In the $result object that the PowerShell script returns to HelloID, you may add a member object called ExportData. Properties of this object and their values will be available after the account has been granted to a user. You can see the code for the object below.

$result = [PSCustomObject]@{ 
	Success= $success;
	AccountReference= $account_guid;
	AuditDetails=$auditMessage;
    Account = $account;

    # Optionally return data for use in other systems
    ExportData = [PSCustomObject]@{
        displayName = $account.DisplayName;
        userName = $account.UserName;
        externalId = $account_guid;
    };
};

In this case, the display name, username, and external ID are returned from the PowerShell target system and may be used in other systems.

When you are finished marking attributes, click the Apply button to apply your changes. Then, click the Force Update Accounts button. This will cause HelloID to update the target accounts as necessary, and pull the marked attributes into Person records for later use by other target systems.

Shared variables are now displayed in the Accounts tab of Person records: 

Use attribute data from another system

After you have configured a target system to store attributes inside Person records, you can access those attributes in other target systems. Here, we will show you how to do this in both a simple target system, and a custom PowerShell system.

Simple target system

Edit the target system in question, and navigate to the Account tab. Then click the wrench icon next to Use account data from systems.

This will bring up a dialog where you may choose which system(s) you'd like to get data from. Choose a system from the dropdown menu at the bottom of the dialog, and click Add. A reference name for the system is automatically generated (e.g., "MicrosoftActiveDirectory"). This name will be used to access the system's information during attribute mapping. When you are finished adding target systems, close the dialog.

Important: You may change the reference name if you wish, but you should only do so before mapping any attribute data. Changing the name afterward will break any existing mappings from that target system.

After adding the system, you will see its information just above the attribute list.

At this point, you may map attribute data from the other target system onto your current one. In the screenshot below, we are taking the givenName attribute from our other Active Directory domain and using it in this one.

Attributes from other systems are available under the Accounts property, followed by the reference name of the other target system.

Custom PowerShell target system

Inside of a custom PowerShell target system, attributes from other systems can be accessed via PowerShell. Edit the target system in question, and navigate to the Account tab. Once there, click on the wrench icon next to Use data from other target systems.

This will bring up a dialog where you may choose which system(s) you'd like to get data from. Choose a system from the dropdown menu at the bottom of the dialog, and click Add. A reference name for the system is automatically generated (e.g., "MicrosoftActiveDirectory"). This name will be used to access the system's information during attribute mapping. When you are finished adding target systems, close the dialog.

Important: You may change the reference name if you wish, but you should only do so before mapping any attribute data. Changing the name afterward will break any existing mappings from that target system.

After adding the desired system(s) you will see its information appear on screen.

When you are ready, you may configure any one of the lifecycle stages. In the PowerShell scripts, you can access information from the other target system(s) in the Accounts property of the Person object. The snippet of code below shows how we can access the givenName attribute from our "MicrosoftActiveDirectory" target system.

# Get givenName from Active Directory target system
$givenName = $p.Accounts.MicrosoftActiveDirectory.givenName;

When we test the results of this script, we can see that a user who has an Active Directory account will get their givenName attribute value populated inside of our PowerShell target system.

What if no account exists in the primary target system?

When sharing information between target systems, you should ensure that any users who receive accounts in the secondary (dependent) system also have accounts in the primary (parent) system. Using our previous examples, if a user did not have an account in our first Active Directory system, then any attempts to use their givenName attribute in another system would result in a blank/null value.

If it is not possible or feasible to ensure that everyone has an account in the primary system, then you should plan your deployment of the secondary system accordingly by using complex mappings and/or scripting to handle blank values.

Dependency resolution order

When you use this feature, the primary target system's entitlements are always resolved before those of the secondary (dependent) system during enforcements. This ensures that the required attributes are available in the primary target system in cases where entitlement actions for both systems occur at the same time (e.g., within the same business rule). See more details in Entitlement action order (dependencies).