10 Replies Latest reply on Jul 9, 2012 1:46 PM by David Pine

    Manager Level 2 as Custom Approval Mapping

      I'm still relatively inexperienced with custom approvals so I apologize if this question doesn't make much sense or if the answer is fairly obvious.


      Basically, I need for a request to always require Manager (level 1) approval while conditionally requiring an additional Manager (level 2) approval based on data stored in one of the SR fields.  I am going to assume I would need to define two rules associated with a new custom process but I'm not exactly sure how to go about defining the "manager" logic.  I tried looking at the OOTB Manager Approval chains but got confused.


      Any help would be greatly appreciated!!


      (SRM 7.6.04 SP2)

        • 1. Re: Manager Level 2 as Custom Approval Mapping
          Jo Pottinger

          Let’s assume you have an SRD called “ABC” where the user will enter a value into the field “Field1”.  If the value entered is “XYZ” you want a two-level management approval process, otherwise just a one-level management approval will do.


          You could achieve this by creating two Custom approval chains.


          One approval chain would have a Selection Criteria of something like:


                    'SRD_Name' = "ABC" AND (Field1' = "XYZ")


          and would be configured to trigger a two-level management approval process.


          The other approval chain’s selection criteria would be:


                    'SRD_Name' = "ABC" AND (Field1' != "XYZ")


          And would be configured to trigger a one-level management approval process.


          For both chains, you just need to add the Process “Service Request – Management Chain” and set the Maximum Levels to be either 1 or 2, for the number of management approvals you need.


          I hope this explanation covers the functionality you’re looking for.

          • 2. Manager Level 2 as Custom Approval Mapping

            Thank you for your gentle nudge in the right direction.  My custom approval workflow actually turned out to be slightly different (and considerably more custom) with 3 approval scenarios but your input gave me the hints I needed to start configuring:


            1) variable X = "a" requires no approvals

            2) variable X = "b" requires two levels of manager approval and then a custom individual approval (1 of 5 people) based on a variable Z

            3) variable X = "everything else" requires only two levels of manager approval


            So, I had to create a new approval process along with a custom "prep get next approver rule" and multiple "get next approver rules" for each of the 5 approvers.  Once this was all done, I followed your guidance and created two new approval chains with selection criteria for the SRD Name in question as well as conditions for "b" and "not a".


            I did realize that my initial "set field" values of Approved Status = In Progress prevented the SR from actually moving out of the "Waiting Approval" status even though there weren't any additional approvers in queue.  Eventually figured it out that the Approved Status needed to be set to "Planning" instead which matched the status flow defined in the Service Request - Level approval process configuration.


            Worked like a charm but a lot to figure out in one day!!



            • 3. Manager Level 2 as Custom Approval Mapping

              This should probably be a separate posting but thought I would at least start by posting here . . .


              If I need to have a predefined GROUP approve an SR based on a condition similar to above, do I have to create another new process or can I somehow utilize the "group" approval type with a conditional approval chain?

              • 4. Re: Manager Level 2 as Custom Approval Mapping
                Jo Pottinger

                It depends what functionality you need.



                1.    If all requests submitted using a specific SRD need to be approved by a defined group, you can just configure the ‘Approval Type’ on the SRD. This will create a related record in the Approval Mapping (APR:Approver Lookup) form for the group you specified.



                2.    If you want a specific subset of requests submitted using the SRD to be approved by the group, you can create a custom chain using the ‘Service Request – Level’ approval process. You would then need to create a record in the Approval Mappings form to scecify the group.



                If the scenario you’re thinking of is any more complex than that (e.g. management approval required foirst, then subsequent group approval required) please provide further details of the use case and I’ll try to point you in the right direction.

                • 5. Re: Manager Level 2 as Custom Approval Mapping

                  Yes, my requirement fits your second scenario . . . specific subset of requests (SR Type Field 10 = "x") for an SRD to be approved by the group.  My head may still be spinning but when you say a create a record in the Approval Mappings form, can you elaborate?  Up until now, I haven't touched this form but am more than willing to learn how to leverage it.  :-)

                  • 6. Re: Manager Level 2 as Custom Approval Mapping
                    Jo Pottinger

                    For SRM, the Approval Mappings form is used when the ‘Service Request – Level’ approval type is used (either by using the “Group” approval type for an SRD, or by configuring an approval chain to use the ‘Service Request – Level’ approval type). The form can be accessed from “Application Admin Console -> Custom Configuration -> Service Request Management -> Approval -> Approval Mappings”.


                    So, for the scenario you described, you would need to create the necessary chain, then a create an approval mapping record, which would include something like:  ‘Approval Indicator’ = “Service Request”, ‘Phase Name’ = “Service Request – Level”, ‘Approval For’ = “Group”, ‘Service Request Definition’ = , then set the Support Company, Support Organization and Support Group fields to specify the approval group you want.  The other fields listed in the Mapping Criteria section are optional and can be used to narrow down the criteria even further.

                    • 7. Manager Level 2 as Custom Approval Mapping

                      Hmm . . . still think I'm missing something here.


                      1) Custom approval chain has been configured with Process Name = "Service Request - Level" and Selection Criteria: 'SRD Name' = "Test SRD" AND ('SR Type Field 10' = "Test Value")


                      2) SRD was configured to use Approval Type = "Group" with Support Group = "Test Support Group"


                      3) Approval Mapping was automatically added by the system after step 2 above with the Support Group Name selected in the SRD ("Test Support Group" with a description of "Created from the Service Request Definition form"


                      Now, with that being said, I went ahead and tested the SR and regardless of what value I select which gets populated in SR Type Field 10, the SR is always being routed to "Test Support Group" for approval . . . which based on the Group approval type, is exactly what I guess should be expected.


                      So, back to my original question.  If I want this SR to be routed to the specified Support Group for approval only if "Test Value" is selected, do I need to define the entire process as a Custom approval or did I overlook some configuration along the way?


                      Thanks again for your input and direction (and patience).  :-)

                      • 8. Re: Manager Level 2 as Custom Approval Mapping
                        Jo Pottinger

                        The initial comment in my previous message was really there to indicate under what circumstances the ‘Service Request – Level’ approval type would be used. For your particular scenario, because you only want a request to require approval if “Test Value” is selected, you would set the Approval Type in the SRD to “Custom” instead of “Group”. As you have found, the “Group” type will always use the specified group, but you want the approval chain you created to be used instead.  Setting the Approval Type to “Custom” is required for approval chains to be used.  You also need to make sure that there is an enabled Approval Mapping record existing for the SRD.

                        • 9. Manager Level 2 as Custom Approval Mapping

                          I'm actually still a little fuzzy on when a new Approver Mapping record needs to be created.


                          However, with that being said, I did create a new Approval Process with a "Prep Get Next Approver" rule type defining SR Type Field 10 as "Temp Char1" and a "Get Next Approver" rule type with the qualification for "Temp Char1" = "ADD" as well as the "Next Approvers" field with a value of SGP000000002792 + " | Request Approver" for the support group in question.  Doing all of this in addition to create a new Approval Chain appeared to do the trick . . . the request is only being held for approval if SR Type Field 10 = "ADD" while all other times is it moving to Planning for backend processing/fulfillment.


                          On further review, even though the "ADD" request is pending approval, none of the members of SGP000000002792 who have "Request Approver" functional role can see anything related to the pending request in their approval queues. I know (or at least hope) that I am close and am only missing one small piece of the puzzle required to get this working 100% as expected.  As I think I mentioned earlier, I followed the exact same process when I needed to define individual approvers and that worked perfectly from start to finish.  My only issue appears to be trying to account for the subtle difference when using a Support Group as the approver.


                          Thanks again for any direction/advice you can provide. :-)

                          • 10. Manager Level 2 as Custom Approval Mapping

                            Okay, after taking a closer look, I found the problem.  I had incorrectly included an extra space in the way I defined the "Next Approvers" value.  Updating it to reflect SGP000000002792 + "| Request Approver" resolved my issue.