Approval reason as required field?

[Former Member]

Dear all,

we are trying to make an approval reason a mandatory field for a role approval. We are making MX_Reason required, but this is a separate attribute. I think the Reason itself is stored in the STATUS attribute piped in with some other data - but is there a way to make it required?

We are on IDM 7.1 with SP 4.

Looking forward to your thoughts,

R.H.

[former_member192665 · Accepted solution]

Hi.

Goto Identity Store Schema => Attributes => Select MXREF_MX_ROLE (or MXREF_MX_PRIVILEGE if you're trying to assign privileges) and then go to the "entry type" tab of the attribute window. Here you can specify that the reason is mandatory or optional.

Cheers,

Kai

[Former Member · Accepted solution]

Hi Kai,

thanks for your answer.

isn't that attribute making the reason mandatory when the request is submitted? We`d like to make the reason mandatory, when our approvers work on the requests. Especially we have the requirement to get a reason if someone rejects.

Kind regards,

R.H.

[Former Member · Accepted solution]

Hi R.H,

Are you able to solve this issue. We do have similar kind of requirement and you said correctly, by making the MXREF_ as mandatory will make the Request reason filed as mandatory but no the approval action reason field. It would be great if you share your solution if you already have one.

[Former Member]

Hi Richard,

Did you managed to get the reason as mandatory before an approve/decline?

I have the same problem here using idm 7.2 with a NW 7.0.

Fadoua

[Former Member]

Hi

The task which you are using to approve or reject there in the attributes tab of the task you can mark the attribute as mandatory

[Frank_Buchholz]

Somehow we've to collect various reasons and all of them should be visible to the next approver or when viewing the history of a request:

• First the requester maintains the mandatory attibute MX_REASON for the request. (This is the easy part.)
• Then the manager adds his reason for accepting or denying the request to another field.
• Both reasons are then shown to the role owner in another approval step who again adds his/her reason to another field.

How can we manage this?

Finaly let's assume that a GRC SoD check adds it's own result to the request just before the manager get's the approval requst.

Does this adds another twist?

Kind regards

Frank

[normann]

Hi Frank,

the reasons are stored in separate table mxi_link_audit along with all the other events of a link between to objects (called reference attribute). Every link has its unique ID and for this link ID there can be and will be multiple rows in the link audit table for every approval step there is.

Unfortunately for the GRC-Integration there is some enhancement necessary in order to get the SoD check result into that table to be able to see it in the audit of IdM later - but that is possible.

Cheers

Norman