Approval procedure - Named approvers of requested business role or organization? (7.1.1)

Hi and welcome to the One Identity Manager forum.

There is indeed no OOTB Approval Procedure Named approvers of requested business role or organization for your use-case  in 7.1.1.

But you can create your own approval procedure to do exactly what you are describing. I am going to walk you through the steps.

NOTE: SQL is for Microsoft SQL Server

1. Create a new approval procedure in the Manager in IT Shop\Basic configuration data\Approval procedures
   • Approval procedure = <Abbreviation to use for the procedure.Something like C7>
   • Description = Named approvers of requested business role or organization
   • No DBQueue Processor task selected
2. Use the Task Change queries for approver selection to open the form to fill in your approver selection query
3. Click on the Add button and set the Approver selection to something like Named Approvers of a role, something to be assigned to
4. User the following query to select the members of the Ruler Container (named approvers) for the role assignment. (Query works only for version 7.1.1 and above).

-- Option for version 7.1.1 and higher
select distinct ro.UID_Person, ro.UID_PWORulerOrigin 
	from PersonWantsOrg pwo join BaseTree /*All Roles*/ bt on ObjectKeyOrgUsedInAssign = bt.XObjectKey
											and bt.UID_OrgRoot not in ('QER-V-NonCompliance', 'QER-V-ITShopOrg', 'QER-V-ITShopSrc')
			cross apply dbo.QER_FTOrgHighestRulerContainer (bt.uid_Org
														, pwo.UID_PersonInserted
														, pwo.UID_PersonOrdered
														, 0
														, 0
														) ro
where pwo.UID_PersonWantsOrg = @uid_personwantsorg

If you want to achieve the same with version 7.0.x or 7.1 you have to use the following query:

-- Option for version 7.0-7.1
select distinct ro.UID_Person, ro.UID_PWORulerOrigin 
	from PersonWantsOrg pwo join BaseTree /*All Roles*/ bt on dbo.QBM_FCVObjectkeyToElement('ColumnValue1', pwo.ObjectKeyAssignment) = bt.UID_Org
											and bt.UID_OrgRoot not in ('QER-V-NonCompliance', 'QER-V-ITShopOrg', 'QER-V-ITShopSrc')
			cross apply dbo.QER_FTOrgHighestRulerContainer (bt.uid_Org
														, pwo.UID_PersonInserted
														, pwo.UID_PersonOrdered
														, 0
														, 0
														) ro
where pwo.UID_PersonWantsOrg = @uid_personwantsorg
union 	
-- could be in the other part of the assignment key
select distinct ro.UID_Person, ro.UID_PWORulerOrigin 
	from PersonWantsOrg pwo join BaseTree /*All Roles*/ bt on dbo.QBM_FCVObjectkeyToElement('ColumnValue2', pwo.ObjectKeyAssignment) = bt.UID_Org
											and bt.UID_OrgRoot not in ('QER-V-NonCompliance', 'QER-V-ITShopOrg', 'QER-V-ITShopSrc')
			cross apply dbo.QER_FTOrgHighestRulerContainer (bt.uid_Org
														, pwo.UID_PersonInserted
														, pwo.UID_PersonOrdered
														, 0
														, 0
														) ro
where pwo.UID_PersonWantsOrg = @uid_personwantsorg

 

HtH

Markus

Hello Markus, thank you very much, thats exactly what I needed. I tested the V7.1 Version and it seems to work very well. Will look at the 7.1.1 version soon.
Best regards, Edi

Hello Markus,

Although the first test was very promising, I found that the 7.1 Version of above SQL statement seems to return the correct members of the appovers group of the requested business role, but mixed with members of another business roles approvers group that has no relation to the one being requested.
This seems somehow intransparent, as I dont really understand the statement, and currently I cannot really track down the possible cause, As i cannot detect any relationship between the two business roles nor the Approver groups.

Do you have an Idea what the reason for the strange bahavior / problem could possibly be?
(I didn't go that deep yout with V7.1.1 yet)

Best regards,
Edi

Hi Edi,

if you do have additional approvers you may want to check the entries in the table PWOHelperPWO for your request (PersonWantsOrg).

I could be the case, that the additional approvers are coming from either the fallback approvers defined at your decision step or the members of the chief approval team.

The property PWOHelperPWO.RulerLevel defines what type of approver this is. 0=normal, 1= fallback, 2=chief approval team

You finde more about the chief approval team in the documentation https://support.quest.com/technical-documents/identity-manager/7.1/it-shop-administration-guide/44#TOPIC-563562 

HtH

Thanks Markus,

In PWOHelperPWO I checked all evaluated Approvers of Level 1, all of them have PWOHelperPWO.RulerLevel = 0 (normal) so no Fallback or Chief approvers involved.

Also I verified the Workflow for no fallback approvers and the Chief approval team role not being populated.

In fact it seems additional undesired approvers for Level 1 are taken
A) from the approver group of one specific business role which seems to be unrelated to the one being requested.

(If I removed the Approver Group from that business role the undesired approvers do not show up in PWOHelperPWO)

PLUS additionally

B) i have see two "empty" level 1 appovers in PWOhelperPWO where the values for
UID_PWOHelperPWO
UID_PersonHead
are not set.

I see
Level 1 approver A - Correct
Level 1 approver Empty
Level 1 approver B - Correct
Level 1 approver Empty
Level 1 approver C - Correct

Any other ideas to track down why the
unwanted approvers and the "empty" approvers come from?

i greatly appreciate any thoughts on this.

Best regards,
Edi

First thing i would do, test your SQL query used in the step and check the results for the PWO in question.

Secondly, did you use one of the SQLs i proposed? If so which one, and are your sure you made no modifications?

Hi Markus
The SQL Query returns exactly the same number of Approvers as I described above.

I use the very same script above for Version 7.1 as we didnt go to 7.1.1 yet.

I've tested both SQL version in my 7.1.1 version and they work as expected. Both versions work in 7.1.1 that's why i've used one database for testing.

But you mentioned that you have "empty" level 1 approver in PWOHelperPWO with an empty value for the PK UID_PWOHelperPWO is empty. This is highly unlikely as there are primary key constraints in place that would throw an error.

I am doubting that those entries are generated by the system. Do you have custom triggers in place in your database?

 

Hi Markus, thanks again,

No, we dont have any custom Triggers, but we do have some custom Processes on the Table [Org]

Actually I see the information I gave you is partially incorrect, it might be due to a timing issue where not all attributes have been populated yet when i checked.

Correct is
B) i have see "empty" level 1 appovers in PWOhelperPWO where the values for
UID_PWOHelperPWO is set
UID_PersonHead is not set.

What I further observed:
The number of "empty" level 1 approvers seems to be ((total level 1 approvers) - 1).
I've seen this during different tests, but not sure this is consistent all times.


Best regards,
Edi

• Is this the only decision step in the workflow?
• Can you post a screenshot of the PWOHelperPWO entry with the empty UID_PersonHead and from a correct one from inside ObjectBrowser?

Maybe that helps solving the riddle.