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

25 Kudos

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>