What variables are available in provisioning policy field value scripts and rules

[#1]

• FieldValue rule signature
• This is a complete list of what is actually available to you
• Example from a real provisioning scenario
• Set prior to running the rule/script
• Variables from the workflow step arguments
• Variables already calculated from the provisioning policy for previous fields
• Beanshell standard variables

FieldValue rule signature

If you look at the signature for any FieldValue Rule it looks like this:

• identity
• log
• context

In reality, there are many more variables provided at run-time for users in order to use when generating their field values.

This is a complete list of what is actually available to you

• All script arguments from the workflow step that called this (if using a workflow step to call to the compileProvisioningProject workflow method)
• Field values that have been processed so far from the Provisioning Policy related to the Application/Role in question
• identity - the identity being acted upon
• link - the account link being acted upon
• project - the provisioning project
• accountRequest - the specific account request related to this provisioning policy if it's an account request
• objectRequest - the specific object request related to this provisioning policy if it's an object request (creating or modifying a group in LDAP/AD for example.)
• role - the role being provisioned if this is a role request
• application - the application that the field belongs to
• template - the template itself that contains all the provisioning policy fields
• field - the current field being computed
• current - ????
• operation (Add, Remove, etc.) - the operation being performed for this field entry

Example from a real provisioning scenario

So if we take an example from a real world scenario, we get the following variables, if we use the   trick from within a FieldValue Rule or the equivalent FieldValue script code associated with the Field in question:

optimisticProvisioning: String = false

objectRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79

field: Field = sailpoint.object.Field@e73a4f

plan: ProvisioningPlan = sailpoint.object.ProvisioningPlan@da6890

context: InternalContext = sailpoint.server.InternalContext@900f3

bsh: XThis = 'this' reference (XThis) to Bsh object: NameSpace: Bsh Object (bsh.NameSpace@a54415)

project: ProvisioningProject = sailpoint.object.ProvisioningProject@ae9c4e

bsf: BSFManager = org.apache.bsf.BSFManager@18cb57

noApplicationTemplates: Boolean = false

userPassword: String = password

link = null

application: Application = sailpoint.object.Application@13c7d2e[id=ff80808141cd69da0141cd69fb8a000d,name=LDAP]

log: Log4JLogger = org.apache.commons.logging.impl.Log4JLogger@10ee4c8

cn: String = Test.Test

identityName: String = Test.Test

group = null

operation: Operation = Add

accountRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79

source: String = LCM

current = null

disableRetryRequest: Boolean = true

dn: String = cn=Test.Test,ou=people,dc=training,dc=sailpoint,dc=com

sn = null

requester: String = spadmin

template: Template = sailpoint.object.Template@1073205

identity: Identity = sailpoint.object.Identity@1b70b7[id=ff8080814200c6e50143df96b76a1c5b,name=Test.Test]

role = null

The following variables can be grouped to show where they came from as shown here:

Set prior to running the rule/script

objectRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79

field: Field = sailpoint.object.Field@e73a4f

log: Log4JLogger = org.apache.commons.logging.impl.Log4JLogger@10ee4c8

context: InternalContext = sailpoint.server.InternalContext@900f3

link = null

application: Application = sailpoint.object.Application@13c7d2e[id=ff80808141cd69da0141cd69fb8a000d,name=LDAP]

identity: Identity = sailpoint.object.Identity@1b70b7[id=ff8080814200c6e50143df96b76a1c5b,name=Test.Test]

project: ProvisioningProject = sailpoint.object.ProvisioningProject@ae9c4e

operation: Operation = Add

group = null

accountRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79

current = null

template: Template = sailpoint.object.Template@1073205

role = null

Variables from the workflow step arguments

These come from the workflow step arguments for the call that runs compileProvisioningProject. These can be seen in the "Identity Request Initlialize" workflow subprocess in the "Compile Project" step.

  <Step action="compileProvisioningProject" icon="Task" name="Compile Project" resultVariable="project">

    <Arg name="identityName" value="ref:identityName"/>

    <Arg name="plan" value="ref:plan"/>

    <Arg name="requester" value="ref:launcher"/>

    <Arg name="source" value="ref:source"/>

    <Arg name="optimisticProvisioning" value="ref:optimisticProvisioning"/>

    <Arg name="disableRetryRequest" value="!ref:enableRetryRequest"/>

    <Arg name="noApplicationTemplates">

      <Script>

        <Source>

            boolean ignoreForms = false;

            if ("ForgotPassword".equals(flow) || "ExpirePassword".equals(flow) || "PasswordsRequest".equals(flow)) {

               ignoreForms = true;

            }

            return ignoreForms;

        </Source>

      </Script>

    </Arg>

optimisticProvisioning: String = false

plan: ProvisioningPlan = sailpoint.object.ProvisioningPlan@da6890

noApplicationTemplates: Boolean = false

identityName: String = Test.Test

requester: String = spadmin

source: String = LCM

disableRetryRequest: Boolean = true

Variables already calculated from the provisioning policy for previous fields

These are by prior fields in the Provisioning Policy (i.e. from the application template for create inside the LDAP application)

dn: String = cn=Test.Test,ou=people,dc=training,dc=sailpoint,dc=com

sn = null

userPassword: String = password

cn: String =Test.Test

Beanshell standard variables

These are native to beanshell and are present in the interpreter already.

bsh: XThis = 'this' reference (XThis) to Bsh object: NameSpace: Bsh Object (bsh.NameSpace@a54415)

bsf: BSFManager = org.apache.bsf.BSFManager@18cb57

[spachipulusu]

Hi Chris,

Above Post explains workflow variables can be used in ProvisioningPolicy Field Value Rules.

Can you specify how can I make use of custom workflow variables in Provisioning Policy Field Value Rule?

Scenario : I have a Custom Workflow with some workflow input variables like RoleName and TicketNumber which will be passed by REST API Program (Holding them as inputs in my workflow)

I have a provisioning policy field value like primaryGroupDN which needs to be calculated based on RoleName, Can I make use of workflow input variables here ?If yes,How?

Right now, I am iterating through project, getting AccountRequests,Getting Attribute Requests for assignedRoles.

But is there any efficient way?

[chris_hajdu]

workflow variables are only passed into the compilation process for use in Provisioning Policy field scripts if you call the compileProvisioningProject workflow method as shown here:

  <Step action="compileProvisioningProject" icon="Task" name="Compile Project" resultVariable="project">

    <Arg name="identityName" value="ref:identityName"/>

    <Arg name="plan" value="ref:plan"/>

    <Arg name="requester" value="ref:launcher"/>

    <Arg name="source" value="ref:source"/>

    <Arg name="optimisticProvisioning" value="ref:optimisticProvisioning"/>

    <Arg name="disableRetryRequest" value="!ref:enableRetryRequest"/>

    <Arg name="noApplicationTemplates">

      <Script>

        <Source>

            boolean ignoreForms = false;

            if ("ForgotPassword".equals(flow) || "ExpirePassword".equals(flow) || "PasswordsRequest".equals(flow)) {

               ignoreForms = true;

            }

            return ignoreForms;

        </Source>

      </Script>

    </Arg>

[satish_kankati]

Hi Chris

Always iam getting  role value as null in the provisioning policy variables even though i requested for role in 7.1.?

Please clarify : objectRequest and accountRequest both the variables iam getting as accountRequest object? What is the maindifference between those?

Thanks

satish

[chris_hajdu]

You should be able to get access to the whole request in the project variable (sailpoint.object.ProvisioningProject) which will contain the compiled version of the plan (sailpoint.object.ProvisioningPlan.)

I just ran a test and the project contained the following informattion which includes the "role" information as well. Look for the MasterPlan section which shows the original request (containing the role request.)

Role request (along with entitlement requests and account requests) will always show up as an AccountRequest object within the plan. ObjectRequests are only for creating LDAP or AD groups (or other types of groups) in connected resources.

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE ProvisioningProject PUBLIC "sailpoint.dtd" "sailpoint.dtd">

<ProvisioningProject identity="spadmin">

  <Attributes>

    <Map>

      <entry key="noApplicationTemplates">

        <value>

          <Boolean>true</Boolean>

        </value>

      </entry>

      <entry key="noCreateTemplates">

        <value>

          <Boolean>true</Boolean>

        </value>

      </entry>

      <entry key="noFiltering">

        <value>

          <Boolean>true</Boolean>

        </value>

      </entry>

      <entry key="noFilteringRetains">

        <value>

          <Boolean>true</Boolean>

        </value>

      </entry>

    </Map>

  </Attributes>

  <MasterPlan>

    <ProvisioningPlan>

      <AccountRequest application="IIQ" op="Modify" targetIntegration="IIQ" trackingId="0398ffb3e49a4579801b5885817f24d0">

        <Attributes>

          <Map>

            <entry key="provisioningTransactionId" value="ff8080815b7cbda1015b86bcb26b00d9"/>

          </Map>

        </Attributes>

        <AttributeRequest assignmentId="a718da88b5ad4178b936ed854146711e" name="assignedRoles" op="Add" trackingId="0398ffb3e49a4579801b5885817f24d0" value="PRISM Super"/>

      </AccountRequest>

      <Attributes>

        <Map>

          <entry key="source" value="LCM"/>

        </Map>

      </Attributes>

      <ProvisioningTargets>

        <ProvisioningTarget assignmentId="a718da88b5ad4178b936ed854146711e" role="PRISM Super">

          <AccountSelection applicationId="ff8080815b113bbb015b113bd5d5001b" applicationName="PRISM" selection="spadmin">

            <AccountInfo displayName="spadmin" nativeIdentity="spadmin"/>

          </AccountSelection>

        </ProvisioningTarget>

      </ProvisioningTargets>

    </ProvisioningPlan>

  </MasterPlan>

  <ProvisioningPlan targetIntegration="IIQ">

    <AccountRequest application="IIQ" op="Modify" trackingId="0398ffb3e49a4579801b5885817f24d0">

      <AttributeRequest assignmentId="a718da88b5ad4178b936ed854146711e" name="assignedRoles" op="Add" trackingId="0398ffb3e49a4579801b5885817f24d0" value="PRISM Super"/>

    </AccountRequest>

  </ProvisioningPlan>

  <ProvisioningPlan targetIntegration="Custom">

    <AccountRequest application="Custom" nativeIdentity="spadmin" op="Modify">

      <AttributeRequest name="groups" op="Retain">

        <Value>

          <List>

            <String>group1</String>

            <String>group2</String>

          </List>

        </Value>

      </AttributeRequest>

    </AccountRequest>

  </ProvisioningPlan>

  <ProvisioningTarget assignmentId="a718da88b5ad4178b936ed854146711e" role="PRISM Super">

    <AccountSelection applicationId="ff8080815b113bbb015b113bd5d5001b" applicationName="PRISM" selection="spadmin">

      <AccountInfo displayName="spadmin" nativeIdentity="spadmin"/>

    </AccountSelection>

  </ProvisioningTarget>

</ProvisioningProject>

[satish_kankati]

Chris .

Thanks for your reply. Iam getting the role information inside the project when i requested as you mentioned above. My question is when i dump the bean shell variables inside the field  its displaying so many variables like mentioned earlier

optimisticProvisioning: String = false

objectRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79

field: Field = sailpoint.object.Field@e73a4f

plan: ProvisioningPlan = sailpoint.object.ProvisioningPlan@da6890

context: InternalContext = sailpoint.server.InternalContext@900f3

bsh: XThis = 'this' reference (XThis) to Bsh object: NameSpace: Bsh Object (bsh.NameSpace@a54415)

project: ProvisioningProject = sailpoint.object.ProvisioningProject@ae9c4e

bsf: BSFManager = org.apache.bsf.BSFManager@18cb57

noApplicationTemplates: Boolean = false

userPassword: String = password

link = null

application: Application = sailpoint.object.Application@13c7d2e[id=ff80808141cd69da0141cd69fb8a000d,name=LDAP]

log: Log4JLogger = org.apache.commons.logging.impl.Log4JLogger@10ee4c8

cn: String = Test.Test

identityName: String = Test.Test

group = null

operation: Operation = Add

accountRequest: AccountRequest = sailpoint.object.ProvisioningPlan$AccountRequest@4e8c79

source: String = LCM

current = null

disableRetryRequest: Boolean = true

dn: String = cn=Test.Test,ou=people,dc=training,dc=sailpoint,dc=com

sn = null

requester: String = spadmin

template: Template = sailpoint.object.Template@1073205

identity: Identity = sailpoint.object.Identity@1b70b7[id=ff8080814200c6e50143df96b76a1c5b,name=Test.Test]

role = null

my question is when we will get the role(bolded above) value as not null. Iam getting in all the cases role is null. what is the use of these variable.?

[mloessl]

@chris_hajdu it seems to me that the information in this article is not 100 % correct.

According to https://community.sailpoint.com/t5/IdentityIQ-Forum/Identity-Refresh-problem-with-Refresh-assigned-d... identity is only available inside a Field Script after requesting the role (e.g. via Manage User Access). On a subsequent Identity Refresh with Refresh assigned, detected roles and promote additional entitlements or Provision assignments enabled, the identity variable is empty and therefore useless:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Identity PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Identity/>