How to set nextLaunch or date in API call to "scheduled assignment " workflow. This workflow for sunrise/sunset role assignment does not take date as input.
Do the AttributeRequests in your provisioning plan contain the sunrise/sunset attributes? If not, then you can also create a custom intermediate Workflow which launches the “Scheduled Assignment” Workflow via the RequestManager and adds the delay into the RequestManager itself.
In general, you can use wait steps in your workflow to background subprocesses and control when they’ll launch next. In this case, though, you’re asking about a role assignment, which is immediately added to an Identity with a “start” and “end” date:
<RoleAssignment assigner="spadmin" assignmentId="e42ff308ce2c47ad9c9dcd94e51270f5" date="1642536300762" endDate="1674972000000" roleId="c0a8010c777319d3817773db72ed010d" roleName="Benefits Manager" source="LCM" startDate="1674021600000">
...
</RoleAssignment>
Every time an Identity Refresh task with the “Provision assignments” option runs, it will check this assignment to determine if it’s time to kick off yet. The date is completely irrelevant to the workflow launch time because the assignment is immediately added to the Identity with a start date set sometime in the future. It’s only relevant to the refresh task.
As for how the date itself gets passed in, it comes in as an “addDate” argument on the AttributeRequest in the ProvisioningPlan.
i’m not sure if your comment relates to my query. There is no provisioning plan passed to the standard “scheduled assignment WF”. I am just trying to find if and how i can pass date as an input in my REST call to sailpoint standard WF “scheduled assignment” as i can’t see that as one of the WF inputs or can i create a request object using API call with a next launch date something like mentioned in my message below
@bernie_margolis your understanding here is incorrect.
If we enable sunrise/sunset assignment in IIQ and request access for a role (with future sunrise and sunset dates) using manage user access, LCM provisioning completes immediately and a request object is created in IIQ with date attribute and nextLaunch date and it executes based on the nextLaunch date.
Now the question here is as im trying to replicate this functionality via API calls can i use nextLaunch or date attributes in my API call even though the WF (scheduled assignment ) doesn’t have that attribute as an input.
What API call are you making? Like @paulo_urcid and I said, the date is passed in through the AttributeRequest on the ProvisioningPlan. The workflow indrectly has that attribute as an input via the “project” argument. The ProvisioningPlan is passed in on the ProvisioningProject, and the “addDate” argument is passed in as an attribute on an AttributeRequest in the ProvisioningPlan.
i am planning to use /scim/v2/launchedWorkflows . Now when we use this API we can provide “workflowName” and “inputs” which correspond to inputs on the actual workflow (here scheduled assignment). I get what you’re saying about project but dont think the API call from ServiceNow can make this project and hence was trying to replicate what the requestobject is doing here. Project is basically calculated within the WF based on the inputs we provide.
So - could we add a simple step in the ‘LCM Provisioning’ workflow here that would take as input the request details (create a new workflow variable for this) - then uses beanshell to assemble a valid ProvisioningPlan - and saves it to the workflow in the $plan variable? You’d also want to include some logic so that this step only runs when your new workflow variable is populated (indicating it came from your API call vs. standard “manage user access” operations.
You could then continue on through the normal ‘LCM Provisioning’ workflow once the plan is manually created.
Another option would be to run through an example of your use case using the IIQ UI, with ‘LCM Provisioning’ workflow variable ‘trace’ set to ‘true’. Then, grab the XML of the plan from the logs - and use this as a model of what to send in subsequent requests. This could be tricky, as the plans could look different depending on how many objects are being requested etc.
thanks @adam_creaney - yes, i am planning to do that . Snow API call to my custom WF wherein i build the plan and then call LCM provisioning with just removeDate (as business wants immediate sunrise and future sunset).
Hi ,
I tried the below code to generate the immediate sunrise, future sunset plan(after 1 day) -
if(idLink !=null){
log.error("Build immediate sunrise and future sunset plan");
workflow.put("accountProvisioned",idLink.getDisplayName());
//Build account request
ProvisioningPlan.AccountRequest accReq = new ProvisioningPlan.AccountRequest();
accReq.setApplication(applicationName);
accReq.setOperation(ProvisioningPlan.AccountRequest.Operation.Modify);
accReq.setNativeIdentity(idLink.getNativeIdentity());
ProvisioningPlan.AttributeRequest attrReq1 = new ProvisioningPlan.AttributeRequest();
attrReq1.setOperation(ProvisioningPlan.Operation.Add);
attrReq1.setName("memberOf");
attrReq1.setValue(groupDN);
attrReq1.setAddDate(date);
attrReq1.setRemoveDate(addDays(date,1));
accReq.add(attrReq1);
List attList = accReq.getAttributeRequests();
//Only Push to LCM Provisioning if their are attributeRequests
if (attList != null) {
wfcontext.getWorkflowCase().put("proceedLCM",true);
}
plan.add(accReq);
log.error("sunrise sunset plan is:"+ plan);
}
the code ran successfully, and in entitlement for a person I could see deactivation date being populated, but when I checked the request object there was no request created for future execution -
And as expected the problem is that even after the sunset date passed the entitlement has not been removed.
Please advise if i’m missing something in plan ? (ignore the log.error statements, will change levels later)