Hi Guys
I have made a review on some app roles and want to automatic have them removed after approver have selected revoked on the user. The review works fine, but i dont know how to proceed to pass it on to the AFX, to remove the App role.
Do I need to create a workflow under Reviews? (Marked as Revoked)
Please point me in the right direction, ty.
Best regards
\Martin
The removed entitlements would follow the approval/fulfillment workflows initially set on their respective Directories/Applications at first. If that is not set, then the request workflow set (in the Requests > Workflow > Overview page depending of the type of review) should be configured to call fulfillment workflows for these changes coming out of the review.
The first option of setting the fulfillment workflows on the directory/application side, not only for review use, but for any change, is the correct way to go though.
Perfect now I understand.
But I have a last question regarding the workflow. We are pulling entitelments from a MS DB. We are pulling
Name, ENT ID, description, custom ID.
We have choosen Name as the Application Role ID/Name in the entitelment collector, but when we want AFX to remove the entitelment then we want it to use the custom ID of the entitelment instead. Is that possible?
So let's agree first that the custom id is a unique id for each AppRole there inside the MS DB table that has the AppRole your collector is collecting from.
From AFX's perspective with an MS DB connector, the removal (or any other capability) will have an SQL statement to invoke on the MS DB. In the remove AppRole from account/user capability you will be relying here on to removing the AppRole from the user, I assume a DELETE statement will be run on a table that contains a relation between the AppRole and the user/account that would look something like this:
DELETE FROM <APPROLE_X_USER/ACCOUNT> where <USER/ACCOUNT_ID> = <USER/ACCOUNT_ID/NAME_IN_REVIEW> and CUSTOM_ID=<CUSTOM_ID_OF_APPROLE>;
If the Custom ID is not something populated in that table that contains the relation between AppRole and Account/User (exists only in the table that has approle data), you can use an extra where clause to let's say determine the name of the AppRole from it's custom id:
DELETE FROM <APPROLE_X_USER/ACCOUNT_TABLE> where <USER/ACCOUNT_ID/NAME> = 'USER/ACCOUNT_ID_IN_REVIEW> and APPROLE_NAME=(SELECT <APPROLE_NAME> FROM <APPROLE_TABLE> WHERE CUSTOM_ID=<CUSTOM_ID_OF_APPROLE>);
** The following variables would be resolved with an actual value at CR runtime based on the CR items inside the CR:
<USER/ACCOUNT_ID/NAME_IN_REVIEW>
<CUSTOM_ID_OF_APPROLE>
** The USER/ACCOUNT_ID, AppRole Name & CUSTOM_ID values should be available at runtime in OOTB workflow variables since the change item inside the change request resulting from the revoke in the review will contain a user/account and an AppRole ; meaning that metadata for the user/account and AppRole involved (anything from user/account data and entitlement data whether AppRole name, AppRole custom id, etc..) should be available for use at runtime if the fulfillment workflow is configured to "create an individual job for each item" if you will be using a provisioning command node in the WF to provision the changes instead of using the normal AFX fulfillment handler. If you are using the normal AFX fulfillment handler method, you can map those user/account & AppRole attributes to your capability's parameters and load those parameters in the SQL statement that would resolve to actual values on runtime as well.
I hope that was clear enough.
Hi Ahmed
Thank you very much for taking time to answer my questions, and it was an eye opener, but it is alittle unclear for me how to get the variables in the WF, when I want to use the provisioning in the WF. I know how to get the identity ${access_request_cri_meu_userId}, but how do i pull the:
- account
- and which app.role to remover?
from the requst.
Best regards
/Martin
For you to be able to use the variables inside your fulfillment workflow, the fulfillment workflow needs to be grouped to "create an individual job for each item" to be able to resolve the WF variables accordingly since the fulfillment workflow has a dedicated instance for each item inside the CR.
The method I use to get the actual OOTB WF variable name/syntax is that I add a dummy SQL Select > Right Click > A menu like present in the following screenshot will appear > see which WF variable is needed > Click on it > It's name ${{access_request_cri_xxxxx} will be present in the SQL node text box for you to copy and paste somewhere else > delete the node after it isn't needed.
After obtaining the correct syntax, you can pass them on to your provisioning node. If you are going to use the AFX fulfillment handler (no provisioning command), there is no need for all of this as the account and approle attributes will be mapped to the AFX capability's parameter then fed to the SQL DELETE statement.
Thank you very much Ahmed. I have every thing up and running now. Couldn't have done it without you, really appreciate.
Wish you a merry Christmas and a happy new year,
Best regards
\Martin
Thanks Martin Merry Christmas and a happy new year to you as well 
For you to be able to use the variables inside your fulfillment workflow, the fulfillment workflow needs to be grouped to "create an individual job for each item" to be able to resolve the WF variables accordingly since the fulfillment workflow has a dedicated instance for each item inside the CR.
The method I use to get the actual OOTB WF variable name/syntax is that I add a dummy SQL Select > Right Click > A menu like present in the following screenshot will appear > see which WF variable is needed > Click on it > It's name ${{access_request_cri_xxxxx} will be present in the SQL node text box for you to copy and paste somewhere else > delete the node after it isn't needed.
After obtaining the correct syntax, you can pass them on to your provisioning node. If you are going to use the AFX fulfillment handler (no provisioning command), there is no need for all of this as the account and approle attributes will be mapped to the AFX capability's parameter then fed to the SQL DELETE statement.