I am trying to understand the path of least resistance to populate necessary attributes for a ITSM integration to properly reflect the requester/requestee in the ITSM ticket. We are using the generic service desk integration for this. From the thread above, it seems that the planInitializerScript is not actually valid? I tried a very simple planInitializerScript and I do not seem to be getting what I want in my plans arguments, but could be something wrong on my end. Trying to understand if it is actually not running though based on Neil’s response in the above. I do not want to go through professional services to deploy a BeforeProvisioning rule. Going to dig further here in my DevRel tenant so I can see some VA logs in the meantime.
It seems like there may be another option around this, but the documentation is not great. This page of the documentation mentions something about setting a “Requestor Source” which I would be willing to set up a source to aggregate the user accounts from the ITSM system for ID references, etc, but how would I reference them during the ticket creation Velocity if I go through the trouble of setting this up? Anybody have any experience with this yet?
So it turns out the planInitializerScript does indeed run which is great, so I can easily grab identity attributes and put them in the plan arguments to reference in the velocity of the ticket fields. I am however still curious about this “Requester Source” if anybody still has insights there.
I’m evaluating options for adding additional data to SDIM tickets and stumbled on this. How did you get planInitializerScript to work? Is the beforeProvisioningRule on your Service Desk Integration configured with Sample Before Provisioning Rule for SDIM?
I’ve tried a couple different formats to add extra data to the plan arguments using planInitializerScript but haven’t had any luck. I assume it’s because that OOTB Before Provisioning Rule is attached, but I can’t find a way to remove it.
As for Requester Source, that seems to be utilized in the Sample Before Provisioning Rule for SDIM rule. The rule code uses it to populate the opened_by and requested_for arguments/variables with the nativeIdentity of the account for the corresponding identity in the Requester Source.
I removed the Sample Before Provisioning rule because it’s undocumented and doesn’t come back in an SP-Config export, so I didn’t want it interfering with anything I was trying to do. You should just be able to remove it with the appropriate API call or VSCode plugin.
EDIT: I went back to the integration source after I read this and it appears the before provisioning rule adds itself back somehow after a few minutes… so I guess it cannot be removed.
The format for the planInitializerScript is very simple. Just put beanshell straight into the value of the key. The create service desk integration endpoint has the value as an XML rule, but that did not work, so it should look like this:
"planInitializerScript": {
"source": "//Get the plan arguments so we can add to them\n Map arguments = (Map) plan.getArguments();\n if (arguments == null) {\n arguments = new HashMap();\n }\n \n //Add all plan identity attributes to a map argument\n arguments.put(\"identityAttributes\", identity.getAttributes());\n plan.setArguments(arguments);"
},
Where did you find the source code for the sample rule? I couldn’t find it anywhere. That is good to know, so thank you for pointing that out.
You can then reference these arguments via velocity like so:
I tried your example script as-is, but I’m not seeing identityAttributes in the plan arguments. I still see the arguments added by the OOTB rule.
I’m guessing it’s a tenant config/feature-flag difference disabling the planInitializerScript for me. I know SailPoint is trying to move away from that in ISC in favor of before provisioning rules that go through their review process.
I was lucky to have saved the OOTB rule from the /cc/api/rule/list API before it was disabled. Not sure on SailPoint’s policy for sharing their rules otherwise I’d upload it here.