- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Simple workflow request
Hi everyone.
Can I ask for "easy" help?
I am studying the workflows within IGL 7.1.
I would like to ask you for a little help as documentation is not so clear for me.
In an authorization workflow of a request, I would like to make a simple external SQL call to verify a value and, based on the result of the query, give OK or KO to the request. I think it is easy but I have never seen how it is done.
For example I would like to put a decision in the middle of the workflow that says:
- query to a db (maybe the same igl db if possible).
if the user for whom authorization is requested has title=manager then ok, approve otherwise deny the request.
I can't understand how to creta a value with the result of the query and to use it for subsequent processes (ok or deny).
Can you help me with an example?
Thank you very much!!!!
Shanelle
- Tags:
- Access & Change Requests
- Community Thread
- Discussion
- Forum Thread
- Identity G&L
- Identity Governance & Lifecycle
- IG&L
- IGL
- RSA Identity
- RSA Identity G&L
- RSA Identity Governance & Lifecycle
- RSA Identity Governance and Lifecycle
- RSA IGL
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
As mentioned earlier, a simpler way may be to simply restrict who can use the request buttons. As an example, you could restrict the 'Add Access' button to only those users with a certain Title:
You'd then know the request was raised by a 'Manager' and wouldn't need to perform calculations within the workflow.
However, in response to your question around how to create a value. Firstly, never update the out of the box workflows as these could be change/updated/overwritten when you patch/upgrade. Instead create a new workflow and use the Copy From option.
Use the SQL Select node to query the IGL database. As example, the following query checks the Title of the user that the Request has been raised for ('${access_request_cri_meu_title}'), these variables are available by right clicking within the workflow node. Set the Variable Type to Job - there are other types available, details of which can be found on the community.
Once you save the workflow, the new ISMANAGER Variable will be available to select.
Then, using a Decision Node you can use the 'Workflow Variable' option to determine your transition criteria:
You then need to use Transition Nodes to route the request accordingly. You must have a True and a False transition. For the True transition, make sure the 'Evaluated to True' tick box is set
To summarize:
1. Queries the IGL DB to calculate the variable that will be used to determine how the request is handled
2. Uses the Variable from 1 to route the request accordingly
3. Where the request is for a user with the Title 'Manager' the request will be sent for approval (in this example)
4. Where the request is for a user where the Title is not 'Manager' the request will be cancelled
As always, please take backups and first make changes in a non production environment.
Additionally, workflows can grow and become unnecessarily complex - it's always worth considering if there's a simpler more out of the box approach before adding to the workflow logic.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi Shanelle,
Although what you described sounds achievable, it would be interesting to fully understand the use case as there may be a simpler approach.
Some questions:
- Is this required for ALL requests no matter what is being requested?
- Should only users with the Title 'Manager' be permitted to raise requests?
Personally I think it would be better to try and stop the Request even being raised instead of raising and then cancelling.
Thanks,
Clive
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi,
my idea is to configure specific requests flow for each application.
In this case, I would apply the flow of authorization request that start from an user or from his manager.
So, let's say a manager starts a request (maybe with a form) to add an entitlement for a person.
This should fire a request workflow with some approval steps.
I would like to start with a simple use-case and so in some part of the workflow a query to a database (maybe the same igl db if possible) will check for the title value of the user: if the value title=manager then the request is approved, otherwise no.
With the occasion I would understand how to create a value, add the result of the query on it and to use it for subsequent processes (ok or deny).
Thanks
Shanelle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
As mentioned earlier, a simpler way may be to simply restrict who can use the request buttons. As an example, you could restrict the 'Add Access' button to only those users with a certain Title:
You'd then know the request was raised by a 'Manager' and wouldn't need to perform calculations within the workflow.
However, in response to your question around how to create a value. Firstly, never update the out of the box workflows as these could be change/updated/overwritten when you patch/upgrade. Instead create a new workflow and use the Copy From option.
Use the SQL Select node to query the IGL database. As example, the following query checks the Title of the user that the Request has been raised for ('${access_request_cri_meu_title}'), these variables are available by right clicking within the workflow node. Set the Variable Type to Job - there are other types available, details of which can be found on the community.
Once you save the workflow, the new ISMANAGER Variable will be available to select.
Then, using a Decision Node you can use the 'Workflow Variable' option to determine your transition criteria:
You then need to use Transition Nodes to route the request accordingly. You must have a True and a False transition. For the True transition, make sure the 'Evaluated to True' tick box is set
To summarize:
1. Queries the IGL DB to calculate the variable that will be used to determine how the request is handled
2. Uses the Variable from 1 to route the request accordingly
3. Where the request is for a user with the Title 'Manager' the request will be sent for approval (in this example)
4. Where the request is for a user where the Title is not 'Manager' the request will be cancelled
As always, please take backups and first make changes in a non production environment.
Additionally, workflows can grow and become unnecessarily complex - it's always worth considering if there's a simpler more out of the box approach before adding to the workflow logic.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Thanks!
Thank you very much Clive!!
It was precisely the clarification I was looking for but I couldn't find it anywhere.
I want to congratulate you because you took great care and attention to explain the tasks with the screenshots too.
May I ask just a question about your comments?
When you say:
" ---> Request has been raised for ('${access_request_cri_meu_title}') "
I think the "access_request" prefix is ready on IGL. Last part "_cri_meu_title" is something you created manually later?
About the prefix "access_request", is there a doc that contains all command, prefix and similar we can use in IGL?
Thanks, really thanks.
Really a nice community
Shanelle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Thank you for the feedback Shanelle and I'm really glad that my response helped.
The ${access_request_cri_meu_title} variable is available to select by Right Clicking within the SQL Select node. This will display a list of out of the box variables and any new ones you've created within the workflow.
See below, Right Click displays a list where you can then choose 'Change Request'. We're then selecting the Title of the User affected by this Change Request.
Hopefully that helps...
Cheers,
Clive
