on 03-06-2013 3:55 PM
As part of IDM (7.2 SP7 ) integration in Client Landscape we are trying to identify how we can group Business Role Approval in a Workflow ?.Please see our case below .
Business Role 1 - Role Owner A
Business Role 2 - Role Owner A
So when we initiate an Approval Workflow (7.2 SP7 New Workflow Process ) based on Pending Value Object , system initiates two separate request for Role Owner or Approver . We like to get this grouped together in such a way that only one request will be routed to the approval with two Business Roles ( 1, 2) are part of the same request This will avoid redundant work by Role owner since both this request are routed to same person . And also we expect if Role owner want to decline one Business role , let the total request be declined & need to reentered with only Business role by Requester .
Please provide any insights in to this case ?
Thanks ,
Jerry George
Hi Jerry,
The current built in grouping mechanism only supports grouping on privilege operations, and while grouping support for roles might be on the roadmap for a later release its probably not what you need right now.
Something that can help you is that when you do assignments from the web-ui there's a request-id set on the assignments. You can use request-id this to find other roles assigned in the same operation. Unfortunately you have to build logic of the role-grouping concept yourself. There's several existing implementations that have used request-object entries or other creative ways to create something like this. You can also specify a request ID when writing mxref_mx_role assignments in passes (see help file).
Some consultants might give some hints or ideas here. My thoughts, not sure if this comes across readable, or if its workable, but I'd try something like this as the validate task workflow and see how it worked.
Ordered task: validate assignment
- Cond. task: Check if assignment is a role assignment *
- True
- Cond. task: Check if there are other role assignments with same request-id *
- True
- Action task: Check if there's a "master" or set this as master **
- Cond. task: Check if a master is already approved
- True
- Action task: Set MX_ATTRSTATE to approved state.
- False
- Cond. task: Check if this PVO is the master
- True
- Approval task: Role owner approval
- Approve
- Action task: approves all objects waiting in *** with same groupid
- Decline
-Action task: declines all objects waiting in *** with same groupid
- False
- Approval task: Wait for role owner approval of master ***
- Approve
- Decline
* these two can be most likely be combined into a single query/conditional statement
** This action task should check if any of the other PVO's have a customer "request_id_master" attribute set.If they dont, assign this as the master task
*** Approval task that is not seen by users, has a system user as approver
I cant give any guarantees for the viability or functionality of the above as I've not tried it or verified it in any way.
Best regards,
Chris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Raju ,
We didn't implement grouping at Business Role level , as Business group removed this requirements based on below ***new****requirements .
We have customized SAP Notification process to fulfill above mentioned requirements .Due to our customization , System will generate Single Emails to Approver Inbox even though different Pending Values will be created at Request Level .We realized this was a much better design , since it provided approvers an option to approve or Reject Request (Partial or Full) , while Emails are grouped which will stop flooding Approvers Inbox
Please let me know if you need more details around this design ,
Thanks & Regards ,
Jerry George
Interesting question. This comes down to either All or None. There is a GROUPING concept for sending the requests to GRC-AC. Shall see if someone else has a suggestion on this.
Cheers
Murali.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
86 | |
10 | |
10 | |
9 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.