Scott Shelton (Customer) asked a question.
Delay fulfillment of User Changes
I am trying to delay the fulfillment of all changes in a request to a date that is different per user. In the request workflow, all the Fulfillment Phase options are set to my fulfillment workflow configured to group based on user and delay accordingly which works for everything EXCEPT User Changes. Specifically Role operations (e.g. remove user from XYZ technical role). The User Changes take place immediately upon entering the Fulfillment Phase, but I do not want that to happen until after my Delay node like everything else. Is there a way to prevent user changes from immediately executing upon entering the fulfillment phase?
In your request workflow, you can add a delay node just before the fulfillment phase node
Note: this approach assumes that all the changes are related to one user.
If there are multiple users, this will probably not going to help you.
Thanks for the response Boris. You are correct that delaying the request workflow works for a single user but not for multiple users, which is the crux of my issue. Since there are multiple users that need their changes fulfilled on different dates in the same request, my testing has shown that the delay needs to take place in the fulfillment phase where the fulfillment workflows are split by user. I tested delaying in the request and approval phases using a subprocess to split on user and delay accordingly, but the workflow waits to start the fulfillment phase until all items have reached the fulfillment phase node as shown below. This is what led me to the conclusion that the delay must be in the fulfillment phase.
I can't think of an alternative how to delay the user changes once fulfilment process starts, as this seems to be behavior of the product.
The only thing I can think of is to break the change request (which has many users) to individual change requests per user.
From the main CR, you will need to parse the content and then send APIs to generate new requests (with the same content) per user.
Then cancel the main CR.
This is only in theory, as I haven't tried it.
@OverthinkerDave (Customer) @TimWillemstein2 (Customer) - what do you think?
To provide a relevant answer, one will need to understand the overall process of how request is being created, why there is a need for a delay and any other supporting information - consider reaching out to RSA PS or RSA partners for a more detailed discussion.
The functionality to group "per user" is already in the product. And currently this product has a lot of bugs related to "calculate (fulfilment) tasks" in requests. And it is slow.
With that said I have had ideas to "split/calculate" tasks outside the product, to then create them one-by-one for specific types of requests.
I would rather (in theory, hehe) try to use the grouping functionality, and FOR EACH group have a "dynamic delay node" that decide when to actually fulfil the request.
I have a thread somewhere in this forum already, that shows my fulfilment workflow (with a built in retry and custom delay for each retry, that changes depending on conditions)
In the solution I am using right now, I have a similar need to "spread the fulfilments out", with the aim not to "overwhelm the AFX" -> and that is very easy to do with randomizer (done with SQL-query)
Se this workflow (which I have published here in this community earlier) to get an idea:
SELECT
sysdate + (to_number(${jobUserData_IterationCounter})*1/86400*15)
as delayed_to_time_value
FROM dual
But I still have a feeling I am missing some requirement from Scott here. I really do not understand the details and reason to delay the requests when you know it is time to fullfill the request.
Personally I try to fulfill "as fast as possible" as soon as the date has passed (given by the user request form).
Is this about onboarding? Because then there are a lot smarter ways to lay out the crumbs on WHEN to say create a Skype account for a group of users.
Anyhow: A very interesting topic, because this part of the product is something that really needs some love.
Today the workflow creation is very slow, which makes me hesitate before coming up with new creative workflows.
Role changes are handled by a different workflow that is configured as fulfillment workflow from the role set of which the role is a part of. This workflow handles add/removes etc. on the role itself. You can find these settings on the Requests page of the role set.