2

This is quite a brief question, and I believe the concept is also small and easily handled so I'll make this short and snappy.

Situation:

  • 6 Approvers.
  • Only two are required to confirm their approval for the step to be declared as approved.

So it's obvious already we can't use Unanimous or the First-Response functionality of approvals.

Remember this can be ANY of the 6 approvers so attempting to delegate it to just two of the six won't work either.

One more thing to note is that we are aware you can create two separate steps where you can basically resubmit the same step twice however we can't (using declarative techniques) omit the user who has already submitted the first approval confirmation so he'd in effect be able to submit it twice, which is not acceptable.

Does anyone have any ideas at all for me? All thoughts much appreciated.

P.S. Potentially open to triggers.

1

Here's an idea (that has some practical limitations). I'll be curious to see if there is a better approach. We'll assume the target object is Foo__c

  1. On Foo__c create five lookups to User: Step2ApproverPoolMember1__c,Step2ApproverPoolMember3__c,Step2ApproverPoolMember3__c,Step2ApproverPoolMember4__c, and Step2ApproverPoolMember5__c
  2. For Step2 of the Approval Process, use the Automatically assign to approver(s) radio button and the add row command and make each row equal to one of the five related user look fields defined in #1
  3. In Step 1 of the Approval process, use a field update as an approval action that updates Foo_c.approvalStatus__c to 'step1Approved`.
  4. Use a before update Foo__c trigger to (if approvalStatus__c is step1Approved and the relatedUser fields are all null to examine the user that approved in step1 and then set the values of the five related user fields to everyone but the step1 approved-by user.

The hypothesis here (and unproven by me) is that the approval step1 approval action field update will update the database before the approval process engine decides which users will see the approval request in the second step of the process.

Assuming the hypothesis is correct, the obvious practical limitation is the fixed number of related User fields defined in Foo__c. If you suddenly had a pool of seven approvers, you'd need to add metadata and change the trigger.

  • Yeah, this is a great theory and a solid explanation to follow. However this is correct there is a large chance that the user base could change, changing metadata is not a solid solution for me. I would have to keep it as dynamic as possible. I'm wondering if the second approval step could pull through the associated users with step 1 at run time and then assess from there. – MattGarnett Apr 20 '16 at 8:39
  • The technique doesn't care if the actual users change, only if the number of approvers in the pool changes. You could define 10 related user fields. – cropredy Apr 20 '16 at 13:29
  • Ah yes sorry, "base" wasn't the correct word to use what-so-ever, instead "user scale" is more fitting. Again, the scale could change sporadically depending on changes. – MattGarnett Apr 20 '16 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.