Would you use an Attribute or a Variable here?

[former_member2987]

Hello Gurus,

I've got a situation here and I'm not sure how I want to proceed, so I'm hoping I can get some input from the IDM Community.

I have a workflow that deals with a Pending Value to handle the approval of various role objects.  The problem is that approvers will get multiple approvals, one for each role that they have.

So I have a couple of thoughts on this and I'm wondering what the best way to proceed is:

1. Create a flag based on AuditID (which is already part of the workflow. I could compare it to an attribute called Z_OLD_AUDITID which would be updated at the end of the workflow.  However this assumes that each notification gets its own AuditID. If this is the right approach, what would work better, an attribute or a Variable?

2. In the notification generation script, update an attribute (or variable) that would be set the first time the task is run with the value NOT set. Then clear the object after the task finishes.

3. Edit the PVO somehow to do this?

I've made it a habit of working with exposed PVOs as much as possible so I'm not as experienced with them.  I'd appreciate any advice here, and of course if you've been in this situation and have a better idea, I'd like to learn about it.

Thanks Much,

Matt

[Former Member · Accepted solution]

Hi Matt,

I am not sure if I understood your problem completely. Who is requesting the n - roles ? Is this a normal role request? And you want to bundle these into one, so that an approver is able to able to approve them together?

I have something similar: I am requesting roles via a custom approval object. This basic approval can be approved by one person. Afterwards, I am splitting and assigning the roles separately.

Jannis

[former_member2987 · Accepted solution]

The basic use case is this:

A designated person (one of three user types) can go in and assign one type of role to be a child of another type of role (that all works fine)

If multiple roles are assigned, notifications are generated for each role that is being attached. We're looking for a way to have one notification go off.  There's no problem with the approval.. The customer wants the approvals for each role, they just don't want multiple notifications.

My thought is that if each role request has a separate auditID, then I can use that.  Track the auditID and compare to a stored value, if the values are equal or the AuditID is greater than the stored value, then the notification should be sent and the auditID stored.

Make sense?

Thanks,

Matt

[Former Member · Accepted solution]

Thats complicated.

Is it possible to add an action task underneath the UI task (where roles are added to roles) to check for the changed role hierarchy and to send out one notification?

[Former Member · Accepted solution]

If they're all kicked off from the same workflow task, they should have the same root auditid.

I assume they're all being approved at the same time by the same person?  Otherwise you're going to have timing issues with notifications (after the first? after the last? on alternate Tuesdays?).

I'd remove the notifications from the approval workflow and build a trigger event that triggers the notification when the required conditions are met (and passing some variablees around).  For instance, your one notification is now going to have to handle x approved, y denied scenarios - unless you have a separate denied notificaitons.

With a trigger type you can have a workflow task which monitors the approvals for the root audit ID and, if all are processed, trigger the notification.  If they aren't, it stores its data and exits.  Only when the last one is processed does it trigger.

Peter

[terovirta · Accepted solution]

Matt Pollicove wrote:

A designated person (one of three user types) can go in and assign one type of role to be a child of another type of role (that all works fine)

Is the approval task triggered for role to role linkages in 7.2? I thought that went away but haven't had a project with role hierarchies recently.

What if you create a custom multivalue-attribute for the role that stores the approver MSKEY in it, like Z_APPROVER_NOTIFIED. When the approval workflow is executed check whether the approver MSKEY exists in that role's Z_APPROVER_NOTIFIED-attribute, if not then add approver's MSKEY and send the notification, if yes then do nothing.

When approving/declining/time outing, clear the approver's MSKEY off the Z_APPROVER_NOTIFIED.

If you would like to send one daily notification then add validity to the attribute value assignment with {VALIDTO="tomorrow"}. With the validity set the attribute gets cleared automatically for the next day.

Am I missing something as it sounded simple?

regards, Tero

[Former Member · Accepted solution]

So, once again Which notifications are we talking about?

- You are assigning roles to roles. NOT roles to users.

- You are talking about the notifications, that somebody has to approve something. NOT that somebody approved or denied an approval.

Correct?

[former_member2987 · Accepted solution]

An interesting idea.  I'll have to look into that.

Former Member I did a lot of database investigating (all the more fun with the IDM DB2 tool, but that's another story. That's pretty much what I found out. So what you're saying is maybe a trigger when there's an ADD to MX_ROLE?  I like that.  Very simple and direct.  Former Member, that seems somewhat doable.

Matt

[former_member2987 · Accepted solution]

Correct on both counts, when the modification to the role is made then the approval needs to occur before it can be finalized. (That assumption was what screwed me up that I mentioned on FB )

[Former Member · Accepted solution]

lol I hate investigating with unfamiliar DB tools - I never know whether I can't find it because its not there or because the tool doesn't behave as I expect.

The event task will work *if* all the approvals are processed at the same time by the same person.  Otherwise you'll still get multiple notifications (which might be fine given different approvals are in action).

If not, you'll need to have a task in your approval tree which counts the number of unapproved assigned roles from the root auditID and if there are none left, call an email task.

Peter

[Former Member]

Each role that is assigned has a separate PVO if I understand what you are saying.  This was unacceptable at a past customer I was at.  I don't know of any way to solve this problem with the standard web dynpro screens, but using SAP UI 5 and the REST API structure, you can easily tie approvals together based on Role ID or Audit ID (and group them by request) as you suggested and you can group them together using the front end.  Then when you send the approval, you send approvals on all the PVOs that were grouped together.

[former_member2987]

Ok, so this means it's theoretically possible.  I'm not really concerned with the UI aspect, just the notifications.  Can you think of a way to do this?

Guess it's time to start throwing things at the wall and see what sticks.

Matt

[terovirta]

How do you want to group them?

a) you add n-number roles to same user at the same time and want to send one notification

or

b) you add n-number roles to the same user and want to send only one notification within given timeframe

And notification is the problem not the n-number different approvals?

regards, Tero