Within RSA IMG (formerly Aveksa) workflows you can assign many resources to complete an approval and/or manual fulfillment activity.
The following screenshot shows an example of resource assigned to an approval activity.
The following screenshot shows an example of resource assigned to a manual fulfillment activity.
There is, on occasion, the need to update the resource assignments, due to some type of personnel turnover – whether the person leaves the enterprise or transfers into another role. When this happens, you find yourself having to edit the workflow.
NOTE: In RSA IMG 6.9 the notion to configure “Other…Owners” for any application, directory, or role set was introduced, but none of these configured used within usable within the workflow layer. This is another reason for this blog by IDMWORKS.
But how do you keep from having to modify these workflows with respect to individual users configured as resources?
IDMWORKS suggests using groups.
Your next question may be: “from where would RSA IMG collect these groups?” Such groups are most likely not maintained in any enterprise Active Directory or LDAP system, nor database, etc.
IDMWORKS recommends coming up with a nomenclature (naming convention) for internally managed groups, such as “my-img-appr-
Once this is determined, a CSV file can be created, mapping each user by their “User ID” (within RSA IMG) to the group. The following is a screenshot example of such a file.
These internal groups can be associated with the application (or role set) they may represent, or to an internally managed Application, such as “My IMG” application. The reason for this because of the account data collector (ADC) you would need to define to collect these users and their respectively assigned groups..
The following screenshot is an example of an ADC collector defined.
Continuing with the CSV file depicted in Figure 3, the following screenshot shows the types configured in the example ADC.
Continuing with the CSV file depicted in Figure 3, the following screenshot shows the accounts data query configured in the example ADC. Note the Account ID/Name mapping compared to the SQL query.
Continuing with the CSV file depicted in Figure 3, the following screenshot shows the user account mapping data query configured in the example ADC. Note that the same values – account and user ID – represent the same user, but within RSA IMG a user can have access to an application only by an account. Therefore the same return value (e.g., user_id) is mapped to User ID as well as Account ID/Name fields.
Continuing with the CSV file depicted in Figure 3, the following screenshot shows the (1) groups data query and (2) account membership query configured in the example ADC. Note the Group ID/Name mapping compared to the SQL query. The account membership query is what helps the internally managed group membership to be leveraged within the workflow, minimizing the need to edit a workflow after assigning the group.
Continuing with the CSV file depicted in Figure 3, the following screenshot shows the user resolution configured in the example ADC.
Continuing with the CSV file depicted in Figure 3, the following screenshot shows the member account resolution configured in the example ADC. Note the target collector is the same as the ADC being configured.
Once the ADC is configured (and saved, by clicking the “Finish” button), click the “Test” button to ensure everything for collections is in order. If the test result pop-up shows XML notation the CSV file is accessible, and the queries within the ADC are sufficient, as shown in the following screenshot.
The next step is to run the collector, but clicking the “Collect Accounts” button, followed by confirming within the pop-up as shown in the following screenshot.
Collecting from this ADC may take a few seconds – depending on the file size or number of lines / rows. By clicking and refreshing the “Collection History” tab for this ADC, as shown in the following screenshot, you can monitor the collection process.
Once the collector completes successfully, confirm the group(s) expected by clicking the “Groups” tab, as well as verifying the account(s) membership as expected, as illustrated in the following screenshot.
Once satisfied, these groups can now be associated as resources in workflows.
The following screenshot exemplifies the ability to search for the group that is going to be configured as a resource. Although the following screenshot depicts an approval workflow, resource search and assignment is the same for fulfillment activity nodes as well.
The following screenshot shows an internally managed group assigned as an approver resource.
The following screenshot shows an internally managed group assigned as a manual fulfiller resource.
If any approver or fulfiller reassignment needs to happen, it’s easy: (1) update the CSV file(s), and (2) run the ADC. That’s it. The next time that activity is invoked, the latest members of the group will be assigned as resources.
IDMWORKS is more than happy to share this 2-in-1 strategy, and is just as willing to discuss other complex implementation regarding RSA IMG (formerly Aveksa).