ARQ: Request Type and Provisioning Actions combination???

[former_member184114]

Hi All,

You may feel upfront that this post is very big. But, I could not find a better way to explain my concern than this!

So, please bear with me 🙂

I was wondering if anybody has experienced the way I am experiencing about below scenarios.

Actually, below request types and their actions I maintained in the confugration:

1. New Account    -> Assign Object

2. Change Account -> Assing Object

I assume that we know what "Assign Object" does here and therefore not explaining this further.

I have also selected "Create user if does not exist for" : Change User Action and Roles Assignment Action

Now the behavior of application goes like this:

NEW ACCOUNT SCENARIO:

I raise a request and request type is "New Account". In "User Access" tab, click on "Add" button and I get "Role" option ONLY (because of above configurations). Now I enter the system name and then search for role(s). If I get those roles, I simply add them in the request. Now I see the "Provisioning Action" drop down, where three actions are possible: ASSIGN, RETAIN and REMOVE.

By default, ALWAYS this is set to "ASSIGN" provisioning action.

Anyway, request is submitted.

The user id which I selected does not exist in the back end system. After going through the workflow, user id is created and the roles are assigned. The user is also notified about this with initial password.

This should ideally happen for "NEW ACCOUNT" request type.

CHANGE ACCOUNT SCENARIO:

Now let's say a user i already created (in above scenario) and now we want to modify his details.

I again access ARQ and raise a request for a user. By default, the request type is "NEW ACCOUNT".

I now select the "CHANGE ACCOUNT" type from the drop down. In order to modify any roles' validity, we need to click on "Existing Assignments" and then select the respective role. Automatically, this will make "Provisioning Action" to "RETAIN" against that role.

Now the confusion is that, even if I select "NEW ACCOUNT" and then try to modify any role assignment by using "Existing Assignments", the Provision Action is set to "REATAIN" for that role.

My question is that, I dont see any tight link/control between request type and provision actions!

What I was looking for is, if I select "NEW ACCOUNT" request type, then provisioning action should automatically set to "ASSIGN" (which is happening by the as of now).

If I select "CHANGE ACCOUNT" request type, then provisioning action should be set to either "RETAIN" or "REMOVE". But "ASSIGN" option should NOT be available!

In simple words:

1. NEW ACCOUNT    -> ASSIGN (ONLY)

2. CHANGE ACCOINT -> RETAIN or REMOVE (ONLY)

If any user misses to select appropriate provisioning action, then system is not highlighting it.

I need a way to make this action also mandatory. I tried by EUP and sE80, but could not succeed.

CAn anybody please advise?

Regards,

Faisal

[Former Member · Accepted solution]

Hi Faizal,

You can select selection for respective actions for request type through "Define Request Type" through SPRO.

Select them as per your need. But remember change account also means assignment of new role to present user for which action assign is required, so make the necessary decision.

BR,

Mangesh

[former_member184114 · Accepted solution]

HI Mangesh,

Thanks for your reply.

Yes, I can select the respective action for respective request type.

As I explained, I selected "ASSIGN OBJECT" for request type "NEW ACCOUNT".

Secondly, I have another question:

It is confusing to have different options here. For example, I can select "CREATE USER" action for new account request type. This at least gives error message if I dont select any system and then simply add role.

As you might know, we have some settings in "Maintain Global Provisioning Configuration" called "Create user if does not exist"

This has 2 check boxes: For Change User Action and For Assign Role Action

If I select both of them, then I only need "ASSIGN OBJECT" action for a request type. Now what happens is that, when I try to assign a role to a user who is not at all available in back end system, then this option creates it without giving any error message.

The only simplicity I have noticed that, you select a role by searching. Which ever back end system that role is coming from, this user is created in that back end system.

It goes the same with "Change User action" option (I have yet to test this).

I still have some sort of confusion here and unable to get these answers as to when this should be used.

Is it possible that you can share what options you are using? How you are tackling this thing?

Can you advise?

Regards,

Faisal

[Former Member · Accepted solution]

Hi Faizal,

Access request form is not dependent on input request type at all.

Second Provisioning actions are not linked to Access request, it is just a way to handle provisioning at the end of approval.

BR,

Mangesh

[former_member184114 · Accepted solution]

Mangesh,

It is quite confusing!

Ideally, a request type should represent the actions being taken on it.

If a request form does not depend on input request type, then chances are that I may get incorrect reports (at least by request type)! Also, the confusion what I am sharing might definitely occur!

I think that you are right. Now I understand that "provisioning actions" are main element to take actions on a request. It is not dependent on request type.

I really do not  understand the need of "request type" if we  have provisioning actions!

I am not sure how others are working on this.

Still, somehow I am not convinced with this kind of application behavior.

I am not sure if any more inputs can be expected!

Regards,

Faisal

[Former Member · Accepted solution]

Hi Faizal,

Request type plays very vital role in defining initiator condition through BRF+, so I would say it is important in that way.

I understand it would be great to have it that way, if user forms would have changed. But I think template based request can be the workaround somehow if you are ready to create some extra entries in system.

BR,

Mangesh

[former_member184114 · Accepted solution]

Hi Mangesh,

Yes, it is important to define initiator rules. But I was thinking from change management and user point of veiws.

If you look at this behavior from these 2 angles, it is quite confusing!

What I strongly believe now is that, instead of request type if we only have "Provisioning Actions" to define the request behavior, it would be very good.

Any way, thanks a lot for your valuable inputs

Regards,

Faisal

[patrick_weyers]

In simple words:

1. NEW ACCOUNT    -> ASSIGN (ONLY)

2. CHANGE ACCOINT -> RETAIN or REMOVE (ONLY)

Hi Faisal,

I disagree, though.

You might have specific requirements, but generally, why should you not be able to use "Assign" in a CHANGE ACCOUNT request?

If I create a request to change an existing user, that may involve retaining existing roles, removing existing roles, but just as well assigning new roles to the existing user.

Regards

Patrick

[former_member184114]

Patrick,

Yes, I agree. This action can be available for Change Account type.

However, with "NEW" account, I strongly believe having "ASSIGN" ONLY suffices.

Regards,

Faisal