I am trying to show custom "Approve" / "Deny" button on Request Fulfillment tickets to only approver members who is part of Current Pending Group.
Approval Groups have created under "assignment" table.
Can i get suggestion how i should check under display option condition whether logged in user is part of current pending groups under assignment table.
Have tried below condition on DO but approver can not see this button on RF ticket.
filename($L.file)="request" and current.phase in $L.file="Authorization" and $lo.pm.assignments isin (current.pending.groups in $L.file)
Hi Jacob Heubner,
Thanks ton for your wonderful detailed explaination on this behaviour pattern in SM.
I referred below link and similar solution worked for this requirement.
Again Thanks lot guys for making me understand this behaviour and hence able to configure this.
The file variable for Display options is $L.filed. Try that.
Have Tried to use below condition but no luck. Is that $lo.pm.assignments is correct local variable im using to fetch logged in user groups ? Please suggest.
filename($L.file)="request" and current.phase in $L.file="Authorization" and $lo.pm.assignments isin (current.pending.groups in $L.filed)
You need to change $L.file to $L.filed everywhere in that condition.
If it doesn't work, pull up an example record where you think the user should be able to see the button, then open Rad Debugger, and try each of the conditions to see what the value is. Such as:
d current.phase in $L.file
d current.pending.groups in $L.file
What version of Service Manager are you using? Are you using Process Designer/Codeless for your Request module?
As per your suggestion i can see correct data for first 3 condition using RAD debugger on specific ticket however unable to test d $lo.pm.assignments via RAD debugger for approver role as its giving permission error for this role.
How to proceed further. Is that $lo.pm.assignments is the correct global variable in which i will get approval group name ?
Also by replacing $L.file to $L.filed under DO condition, still can not see approve button.
Ok, a couple of things then:
First, the OOB Approval functionality in the Request module builds off the required approval definition records you've applied to the phases in your workflow. If you set those up correctly, you shouldn't need to manually set up any additional displayoption records.
Did you generate your ApprovalDef records correctly? Have you applied them to the Approval phase of your workflow, or are you populating the 'current.pending.groups' by some kind of custom code?
Second, if you're using PD, then you shouldn't be adding a displayoption record for your custom buttons. While the tool still technically allows for that kind of old-school coding, PD moved buttons to RuleSet Actions added to the Workflow. So are you sure that trying to put buttons as displayoptions is really the way you want to go?
Hi Jacob Heubner,
Thanks Jacob for your inputs.
You are right. OOB approvals are disabled for Request Fulfillment workflow. However based on Customer requirement we enabled approvals on RF Workflow>Authorization Phases. I am not populating the 'current.pending.groups' by any custom code.
Below steps we performed for approvals mapping and Its working as per the expectation.
1) Created approval records under "Approval Definition" (2 level of approvals) based on specific conditions.
2) first level and second level are groups which created under assignment table.
However challenge with Buttons (for Display option). OOB Approval button is available but condition mentioned below is available.
$L.can.approve=true and open in $L.file=true and lng($L.approval.intersect)>0
And on RF workflow OOB i can see no actions/buttons available on PD RF workflow. Hence trying to customize display option of approve button which must visible to approvers only on RF ticket for which facing challeges.
Ok, poked around and I think I know what your issue is.
In your Approval Definition record, you added the assignment group (from the Assignment table) into the Approvers field. There's nothing inherently wrong with that; that can work. But, look at the operator records for users who belong to that group. In the operator record, in the 'Groups' tab, there's a virtual join to a 'myGroups' table that holds the assignment groups and approver groups for that operator in the 'Member Of' and 'Approver Of' arrays.
Like I said, that's a virtual join, so there's actually a record in the myGroups table with that operator id as the key, and two arrays worth of values. It's this 'Approver Of' array in the myGroups record that the system uses to determine whether or not the operator is somone who can approve for a record.
Any time you add or remove a person from an assignment group record, the system will update that user's myGroups record and change that group in the Member Of; there's also an 'approvers' array in the assignment table. Adding a user here will update that user's myGroups record's Approvers array. Whenever you add or remove an operator from the 'Approvers' array in the cm3groups record, it will update that user's myGroups record and change that group in the Approver Of array.
So, while you have listed the assignment group as the thing the system will use to generate the approval, did you upate that assignment group record to add users to the approvals array, or do you have a cm3group record with the same name with the operators you want listed as approvers in that array? For the operators who are trying to approve, in their operator record on the Groups tab, does it list the groups they are approvers for?