Miscellaneous CUP Questions

[Former Member]

CUP Experts-

Background: We are implementing CUP in a Sandbox environment and things around going well. We are learning more and more about the tool everyday. We have recently upgraded to CUP5.3 SP7 and find it to be a great improvement.

Questions that we are struggling to find answers to :

1) We have our workflow currently designed as such that all requests go through our Security Admininstrators. Due to the newness of CUP for us, we are not allowing requesters or managers to select roles. We are having them ask for a role or a tcode in the Request Reason and Security Admins ultimately choose the role at their stage. Our basic workflow is Requester->Manager->Security Admin->Role Approver. (this is our simple version of the workflow- keep in mind we are at the very early stages of testing) We have 4 different groups of Security Administrators (different parts of the world). We only want them SEEING and selecting roles for their areas. Is there a way we can limit what Security Admins can assign what roles?

2) Since we have a Group of Security Admins, several may be working the CUP "Inbox" at the same time. Is there a way to "lock" a Security Admin out of a request if another Security Admin is already working on it? For example, if 3 Security Admins click on Request 67 to view it and add roles to it, the first one to hit the Approve button essential "wins." The other two will go through all the work and hit Approve and get an error message. This wastes time.

Any info would be greatly appreciated! Thanks in advance.

--

Jes Behrens

[Former Member · Accepted solution]

Jes,

Here is my response to your questions:

1) We have our workflow currently designed as such that all requests go through our Security Admininstrators. Due to the newness of CUP for us, we are not allowing requesters or managers to select roles. We are having them ask for a role or a tcode in the Request Reason and Security Admins ultimately choose the role at their stage. Our basic workflow is Requester->Manager->Security Admin->Role Approver. (this is our simple version of the workflow- keep in mind we are at the very early stages of testing) We have 4 different groups of Security Administrators (different parts of the world). We only want them SEEING and selecting roles for their areas. Is there a way we can limit what Security Admins can assign what roles?

Create a custom field/attribute or use functional area at role level which associated roles with particular functional area or custom field. Now, create a custom approver determinator associated with this func. area or custom field. Now, update the security admin stage with this custom approver determinator.

2) Since we have a Group of Security Admins, several may be working the CUP "Inbox" at the same time. Is there a way to "lock" a Security Admin out of a request if another Security Admin is already working on it? For example, if 3 Security Admins click on Request 67 to view it and add roles to it, the first one to hit the Approve button essential "wins." The other two will go through all the work and hit Approve and get an error message. This wastes time.

This is how it works. There is no way to lock a request.

Regards,

Alpesh

[Former Member · Accepted solution]

>

> Jes,
> 
>   Here is my response to your questions:
> 
> 1) We have our workflow currently designed as such that all requests go through our Security Admininstrators. Due to the newness of CUP for us, we are not allowing requesters or managers to select roles. We are having them ask for a role or a tcode in the Request Reason and Security Admins ultimately choose the role at their stage. Our basic workflow is Requester->Manager->Security Admin->Role Approver. (this is our simple version of the workflow- keep in mind we are at the very early stages of testing) We have 4 different groups of Security Administrators (different parts of the world). We only want them SEEING and selecting roles for their areas. Is there a way we can limit what Security Admins can assign what roles?
> 
> Create a custom field/attribute or use functional area at role level which associated roles with particular functional area or custom field. Now, create a custom approver determinator associated with this func. area or custom field. Now, update the security admin stage with this custom approver determinator.
> Alpesh

Thank you, Alpesh, for your reply.

1) I don't think I'm describing my issue clearly. For example, in our Production world today (not using CUP), we have 4 groups of Security Admins worldwide.

Group A has authority to assign anyone, worldwide, any role

Group B has only the authority to assign roles that areas specific to their region.

Group C has only the authority to assign roles that areas specific to their region.

Group D has only the authority to assign roles that areas specific to their region.

(When I say u201Cauthority,u201D Iu2019m referring to their SAP security in the backend. If Group B tries to assign a role outside their region in CUA, CUA will not allow it. They donu2019t have the necessary permissions).

How do we replicate this in CUP? Is it even possible? Is there a way to limit their background security so if they tried to assign a role that they shouldnu2019t be assigning, CUP or CUA would stop them similar to todays world?

Thanks!!

--

Jes Behrens

[Former Member · Accepted solution]

Jes,

This is very complex and will require some work but it is possible in CUP. It won't be exact same as The steps I have mentioned should totally help in this case. Here are the exact steps:

1) Create a custom field called Authority (at role level). Add attributes in this custom field as Group A, Group B, Group C and Group D.

2) Assign Group A to all the roles and assign Group B, C and D to their respective roles.

3) Create custom approver determinator on the above custom field and assign respective approvers.

Now, when requestor will request 3 roles which falls into Group B, C and D. All four (A, B, C and D) will receive emails to approve those roles. If Group A approves first then all the roles will be approved whereas Group B, C and D folks will be able to approve only those roles which falls into their approval limits.

Regards,

Alpesh

[Former Member · Accepted solution]

>

> Jes,
> 
>     This is very complex and will require some work but it is possible in CUP. It won't be exact same as The steps I have mentioned should totally help in this case. Here are the exact steps:
> 
> 1) Create a custom field called Authority (at role level). Add attributes in this custom field as Group A, Group B, Group C and Group D.
> 
> 2) Assign Group A to all the roles and assign Group B, C and D to their respective roles.
> 
> 3) Create custom approver determinator on the above custom field and assign respective approvers.
> 
> Now, when requestor will request 3 roles which falls into Group B, C and D. All four (A, B, C and D) will receive emails to approve those roles. If Group A approves first then all the roles will be approved whereas Group B, C and D folks will be able to approve only those roles which falls into their approval limits.
> 
> Regards,
> Alpesh

Thanks again for your reply, Alpesh. Your solution seems very doable! However, wouldn't Group A, which would be setup as an approver for ALL roles, see ALL requests in their "CUP inbox" ?

Ideally, even though they can provision all roles, we'd like (for example) Group B to approve security requests in Group B's country and have Group A not see these particular requests in their "inbox."

Is this possible?

--

Jes Behrens

[Former Member · Accepted solution]

Jes,

This is not possible in CUP. Instead, you can make Group A approvers as admin and they can always override and approve or reject any requests.

Regards,

Alpesh

[Former Member · Accepted solution]

Thanks for you help Alpesh. Much Appreciated.

--

Jes Behrens

[Former Member]

Hi, Jes,

On your second question - You may want to try this:

When a security admin logs into CUP to start processing requests, he opens a request and immediately puts that request on hold. This means no other admin can change it. Then, working from the Request on Hold queue, does the research, adds, roles, etc, and then approves the request.

If an admin has several requests on hold and is out of the office, a CUP admin can re-route those requests to the security admin queue for another admin to work on them.

Hope this helps.

[Former Member]

>

> Hi, Jes,
> 
> On your second question - You may want to try this:
> 
> When a security admin logs into CUP to start processing requests, he opens a request and immediately puts that request on hold. This means no other admin can change it.  Then, working from the Request on Hold queue, does the research, adds, roles, etc, and then approves the request.
> 
> If an admin has several requests on hold and is out of the office, a CUP admin can re-route those requests to the security admin queue for another admin to work on them.
> 
> Hope this helps.

This makes sense - thanks for your insight, Jennifer!