IIQ version 8.4p3
I have a use case where after IIQ creates an account for a target connector there is an application support team that wants a work item assigned to them for additional steps they need to perform to complete the full access for the end user.
If it possible to fulfill this through an after provisioning rule? Does anyone have a sample rule they can share?
@talbright So you are looking for creating a manual workitem after account is created.
Never tried this but can you try running below script in after provisioning:
// Build the work item
WorkItem workItem = new WorkItem();
workItem.setType(WorkItem.Type.Generic);
workItem.setDescription("Account created on " + appName + " for user: "
+ identityName + ". Please complete the additional setup steps.");
workItem.setName("Post-Provisioning Task: " + appName + " - " + identityName);
// Assign to the workgroup
Identity owner = context.getObjectByName(Identity.class, workGroupName);
if (owner != null) {
workItem.setOwner(owner);
} else {
log.warn("AfterProvisioningRule: Could not find workgroup/identity: " + workGroupName);
}
// Set priority and notification
workItem.setPriority(WorkItem.Priority.Normal);
workItem.setNotification(true);
// Persist the work item
context.saveObject(workItem);
context.commitTransaction();
Hello Tyrone. Yes, this can be done with an AfterProvisioning rule.
You would probably want to keep the rule thin: identify the account Create, check the relevant provisioning result where present, then launch a small workflow that creates the work item for the support workgroup.
The workflow would then be the place to handle assignment, notifications, escalation, and completion. If you would like it to run asynchronously, RequestManager is worth considering.
If the follow-up should only happen once the connector reports the create as completed, you would want to use Committed rather than Queued.
This work item would definitely only be assigned once the account creation is completed. Do you have an example on how I would script that with the code provided by Neel?
@punna0001 and @neel193 are there any imports I need to specifically include in the rule?
@TyrantDybbuk This is a snippet, you need to write a complete rule and add necessary imports. common ones are:
import sailpoint.object.WorkItem;
import sailpoint.object.Identity;
import sailpoint.object.ProvisioningPlan;
To start with add below ones and give it a try:
import sailpoint.object.*;
import sailpoint.api.*;
import sailpoint.tools.*;
import java.util.*;
Building on @neel193’s snippet, since you only want this once the account Create comes back committed, I would add the check before the launch and let the async part run through RequestManager
for (AccountRequest ar : plan.getAccountRequests()) {
if (AccountRequest.Operation.Create.equals(ar.getOperation())) {
ProvisioningResult pr = ar.getResult();
if (pr == null) {
pr = plan.getResult();
}
if (pr != null &&
ProvisioningResult.STATUS_COMMITTED.equals(pr.getStatus())) {
String workflowName = "Create Support WorkItem";
long launchTime = System.currentTimeMillis() + 5000;
String caseName = "Post-Provisioning Task: "
+ ar.getApplicationName() + " (" + launchTime + ")";
Attributes reqArgs = new Attributes();
reqArgs.put(StandardWorkflowHandler.ARG_REQUEST_DEFINITION,
WorkflowRequestExecutor.DEFINITION_NAME);
reqArgs.put(StandardWorkflowHandler.ARG_WORKFLOW, workflowName);
reqArgs.put(StandardWorkflowHandler.ARG_REQUEST_NAME, caseName);
Attributes wfArgs = new Attributes();
if (plan.getIdentity() != null) {
wfArgs.put("identityName", plan.getIdentity().getName());
}
wfArgs.put("applicationName", ar.getApplicationName());
wfArgs.put("nativeIdentity", ar.getNativeIdentity());
reqArgs.putAll(wfArgs);
RequestDefinition reqDef =
context.getObject(RequestDefinition.class, "Workflow Request");
Request req = new Request();
req.setDefinition(reqDef);
req.setEventDate(new Date(launchTime));
req.setName(caseName);
req.setAttributes(reqDef, reqArgs);
RequestManager.addRequest(context, req);
}
}
}
The Committed check should keep it from launching for a merely Queued result, preferring the specific AccountRequest result where the connector provides one and falling back to the plan-level result otherwise. The idea would be for the Create Support WorkItem workflow to accept identityName, applicationName, and nativeIdentity and create the support work item there.
On the imports, the wildcards @neel193 listed cover most of this. Since AccountRequest is a nested class, you would still need:
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.request.WorkflowRequestExecutor;
import sailpoint.workflow.StandardWorkflowHandler;
This roughly follows the async RequestManager pattern shown here, so it would be worth testing against your connector before relying on it.
Ok. So if I pull together everything you all have shared I attached the rule in theory I would be testing. Let me know your thoughts and I will do some testing.
Rule-After Provisioning-Assign WorkItem.xml (3.5 KB)
@talbright So, you’ll schedule a workflow to launch separately and in the workflow you need to write a code to create workitem. so basically you need to create two artefacts: one after provisioning rule and other is the workflow to create the workitems.
Thanks. I am going to pass this info to my IIQ expert to review your recommendations and setup testing.