The preceding scenario shows a relatively uncomplicated implementation of single manual action. But typical deployments involve more complicated scenarios. For example, a customer might require that when a user is created, an approval goes to a ”bucket’, where one of approximately 25 approvers can select the approval. To mimic a bucket, you can create a work item for each approver in the bucket. All an approver must do is accept the action. Once accepted, Identity Manager can discard the remaining 24 work items, and generates the actual approval work item for the approver who accepted the bucket request.
Consider that there are a total of three buckets that act as escalation tiers. When the approval is processed through Bucket 1, Identity Manager escalates a new request into Bucket 2, and the process begins again. This process results in approximately 26 work items per bucket (25 + 1) multiplied by three (for three buckets). One user request would create 78 work items, granted not all at once. But then consider this occurring in a deployment environment containing a user base of 500,000 users with hundreds of these requests flowing in each day. Had the implementer of this scenario not bothered to size the WorkItem views by using the ExposedVariables argument, Identity Manager would store a large amount of bit of non-essential data in the work items and being passed over the JDBC connection.
<Activity id=’0’ name=’activity1’> <ManualAction id=’-1’> <FormRef> <ObjectRef type=’UserForm’ name=’Access Review Abort Confirmation Form’/> </FormRef> <ExposedVariables> <List> <String>user.waveset.accountId</String> <String>user.waveset.resources</String> <String>user.accounts[Lighthouse].idmManager</String> <String>user.accounts[Lighthouse].fullname</String> </List> </ExposedVariables> <ViewVariables> <List> <String>user</String> </List> </ViewVariables> </ManualAction> <WorkflowEditor x=’53’ y=’111’/> </Activity>