ARQ: Need help on BRF Rule for Decision Table Design???

[former_member184114]

Hi All,

Hope you are doing good!

I need you help to map my business requirement which is explained below:

Currently, I am using 2 request types: New Account and Change Account. "New Account" is used to create a new user account and for also role assignment.

My workflow for both: New and Change Account request types is like this:

Manager->Role Owner

In my current configuration, Roles addition to a request is made "mandatory". Meaning, a request cannot be submitted until a single is added. This goes well if any role assignment/validity extension is needed.

Requirement:

Users' account get expired due to business reason. Now these business users would like to use Access Request application to extend the SAP Account's validity. As I brought to your notice that I have "Change Account" request type configured, I believe (and I would like to use) this can be used to achieve this.

Now what I did is, I made role addition as NON-MANDATORY (in EUP). As a result, if I dont add any roles I CAN submit the request. However, if I dont add anything (Role or System), I can not submit the request, which is good!

Now, when I add system ONLY and submit the request after modifying validity dates, the workflow is getting failed as it can not find the ROLE Owner (As there is no role entry in the request). Therefore, I would like to create another path for ONLY such type of requests (containing SYSTEM entry ONLY).

May somebody help me designing decision table to achieve this and return the required result set? I tried to use different comparison operators. But unfortunately they are not helping!

Can anybody advise to achieve above?

Waiting for your kind response(s)

Regards,

Faisal

[former_member193066 · Accepted solution]

Hello,

You initiator rule must be set as per your requirement.

Create separate path and use logic of prov action, when you have System added only for validity.

you provision action is create ,change etc depends upon you request type action.

in Brf+ you will only see 3 type.. use the logic and send to desperate path,

Prasant

[former_member184114 · Accepted solution]

Prashant,

Thanks for your reply.

I was thinking to use 2 different request types, for example: Change Roles (with Assignment action) and Change Account (with change action).

I believe this will serve the purpose. However, number of request types will be increased. If you notice, currently the "Change Account" request type has: Assign and Change associated actions with it.

I was checking the possibility to use this for both the purposes.

What do you thing will be feasible solution?

Regards,

Faisal

[former_member193066 · Accepted solution]

I use New/Change as 1 request type and Role removal as other, we do not follow for only system validity.

but as per your requirement you may got with system validity access request type.

no harm, just user training , having multiple request type sometimes tedious but help in decision making.

Regards,

Prasant

[former_member184114 · Accepted solution]

Thanks for your reply again.

So have you made role assignment MANDATORY for New/Change Account?

[former_member193066 · Accepted solution]

Its either you can choose system or role..

its always mandatory.

Regards,

Prasant

[former_member193066]

can you send screen shot of your request.

you can use routing rule at stage 1 itself.

Regards,

Prasant

[former_member204479]

Hi Faisal,

To separate out a request type for change validity, we had done the following for a customer:

1. Create a request type "Change Validity".

2. For this request type have actions as change user, user defaults only. This would eliminate the "Add role" option from the request form. It will only give the "Add System" option.

3. For the request type ID created have a different path in your BRF plus initiator.

4. New account and Change account remains same, for add roles and add system.

Let me know if this fits your purpose too.

Thanks

Sammukh

[simon_persin4]

Hi Faisal,

You can certainly achieve this.Why not have a condition on the ROLE-CONNECTOR field which would be populated if the role is there but not if it is a SYSTEM. Use something like, ROLE-CONNECTOR is Initial & vice versa.

You could also have an escape path or a routing rule in case the role approver does not exist which could then move the line-items for system into a different path for something like Application owner.

You could also move away from standard role owner approval and have a custom agent rule which could extend to Role or application owner depending on whatever logic you wish.

Alternatively, re-work your logic to move away from Decision tables and then unlock the wider power of BRF+ and have nested formulae with start / exit conditions to explore more complicated conditional rules.

Naturally, you'll then have to update your workflow paths and approval requirements etc. but as you can see, there are numerous ways that you can achieve this (not necessarily by forcing end users to make mandatory selections etc).

Cheers, Simon

[former_member184114]

Simon,

Thanks for your reply.

Actually, I wanted to use BRF+ decision table to cater to this requirement. I must admit that so far I maintained decision table for initiator rule only. These rules are pretty straight forward.

I also tried to play with different comparison operators, but I could not succeed (I am not striking the right chord!)

I need to still pick up things for BRF+, which is very interesting 🙂

I actually wanted to absorb above mentioned requirement with "Change Request" type. In this regard, I based my condition on "Connector" field. I tried to use different comparison operators, but did not help. When I select any connector, it displays like "XYZCLNT999" (the RFC Name, as we know). I used "equal to", "not equal to" etc but did not work.

I think this contains strings, therefore somehow I feel that if I use "contains" comparison operator, it should return the desired result set.

Can you please advise?

Regards,

Faisal

[simon_persin4]

Ok,

There are some issues with System only as it doesn't behave how you would think it behaves (there are lots of ghost System fields populated based upon inter-dependent data).

If you want to use a decision table, why not create a custom BRF+ element (and add that into the Signature of the Function) then populate that via a DB lookup against the Role ID from table GRACROLE compared with the ROle ID found from the Context. If it exists, then put the value into the field and execute the Decision table. The decision table criteria for that field could then be logically as follows:

Field value is INITIAL then the line item is a SYSTEM = Go down the System Only Approval Path

Field value is NOT initial then the line item is a ROLE as the DB lookup would find the value = Continue on the standard Manager --> Role Owner path.

This logic could easily be worked into a routing rule to be invoked after the Manager approval therefore splitting the request after manager approval. That way, only roles would be directed to the Role Approvers whereas System only lines can be handled differently.

[former_member184114]

Simon,

Thanks for your reply.

I dont know if I am asking too much 🙂

As I have told earlier, I have not used this complex DB Lookup so far. It would be a great help if you can guide me in this. I know it is not good but a step-by-step would really help!

Regards,

Faiasl

[former_member184114]

Hi,

I could search on SCN: DB Lookup and Table Operation types of BRF+ .

I am trying to get acquaint-ant with it steadily.

Regards,

Faisal