is it possible to ADD an AD Group to requesting account if certain condition met in workflow? I have usecase where we need to add an AD group to certain set of user who meet a criterion. I can fetch form variables and put a condition, but not sure i can add an AD group which is not explicitly requested?
FYI - I am using default fulfillment handler, and not provisioning command.
Thanks Mostafa; i came through only these 2 options, either Fulfillment Handler or REST call. i have started development toward REST call, let see if it works. The only question is, is there way i can call REST node between "Calculate Items to Work on" and "STOP"? is it okay? if yes then i will be adding a condition node and REST node.
Yes, just note that adding it there means the second change request will only be created after the first requests is completed and verified.
Also when you insert the REST node there, just make sure you do not delete the existing transition or change its condition. Changing the default condition set on the "All items handled” transition will break the default AFX workflow functionality.
As Mostafa has said this will work but be careful not to break the default functionality within the WF.
However, I am still curious to understand the full use case here. What are the conditions are being met and what is the business process being achieved?
Craig, Condition is based on certain attribute of user level. If flag is true then we want to add user to certain AD group which is not requested as part of Explicit Request.
hi,
would using a role with a role membership rule be sufficient with your use case?
even if it would get provisioned after the initial CR?
frank
Hello Frank,
I don't think its relevant in this scenario.
Hi Hemant,
I was also going to suggest a role with a membership rule based on the user level attribute you have mentioned being set to true or perhaps an attribute change rule to detect if this value is set to true so a CR is properly created.
From your responses I am now assuming this user attribute being set to true is not the only condition that must be met when you wish to add this group. What is the exact use case for a user needing this access so we can advise how this can be done using ootb functionality with full visibility within the UI?
Yes, point noted. I deleted the transition node "All items handled" and recreated it with all required conditions (I took screensnap before deleting, so I can copy the same). hope this will not break anything?
From a Customer Support perspective I want to expand on Craigs cautions with an example. I defer to people more knowledgeable than me about workflow design for the specifics.
1. Using the default AFX fulfillment handler, everything is handled by built in code. Works correctly.
2. Using a custom workflow with custom provisioning nodes, everything handled by the customer. Works correctly.
3. Using the default AFX fulfillment handler, but adding a little tweek to customize it. Fails spectacularly.
The caution here is that must not assume when using a provisioning node that IG&L will handle all the housekeeping for you. If there is an error using the default fulfillment handler, IG&L will normally handle the cleanup. If there is an error in your custom provisioning node its up to you to handle the cleanup.
The biggest issue here is verification. There must be a path for every item in the change request to move to verified dependably. Its trivial to create a provisioning process that creates an opportunity to leave items in a state where they cannot be verified and this leads to many issues downstream.
Hello Ian
Thanks for your response. would you mind elaborating more about pending verification issue? We see that there is already issue with collection closing Watch but not marking pending verification item closed? I see that RSA is planning to release a workaround to close such request using some schedule job? not sure whether it will also help close workflow nodes so we can achieve what we trying as part of customization.
Can this be done? Yes.
Should you do it? No.
How are you planning to scale this? This may work well when you have one change item in the change request but can you scale this when you have 1000 change items? You as a workflow developer will understand this design but how are your administrators going to handle this? Will they be able to tell how this CR was created? How are you going to handle errors when it fails? How will you handle if there are multiple change items for the same user?
I am thinking that you are going to set this workflow to handle one job per item just to work around this problem but you need to understand that this will have a heavy cost on your Workflow table and Workflow engine and the performance.
If you have a set of users that need to have the XYZ group based on their attribute, why don't you create a role with membership rule and use role missing entitlement to achieve this?
Thanks All for your valuable suggestion. I assume this thread as answered. Thanks!
There are generally two ways to call AFX:
You can use some tricks like using a REST node in the middle of your workflow to call the createChangeRequest web service to submit another change requests with the Add Account to Group action you want. However as implied that action would be in a separate change request and not within the flow of your current workflow.
Would you be able to explain the full use case? Perhaps we can provide more relevant suggestions.