Share This:

This Pulse Blog consolidates a number of discussions surrounding the configuration of "non-standard" Approvals for Service Requests, specifically focusing on how to implement an Approval Process (Custom + Approval Chain) to generate Signatures based on a response to question in a Service Request.  There are 3 different Approval Chains shown in the supporting documentation along with examples of how to configure.

This blog is intended to demonstrate the flexibility of the AR/ITSM System and the Approval Engine to meet specific requirements surrounding SRM based Approvals.


I am presenting one method of implementing Approvals based on a Response to a Question returning a Remedy Login ID(s) where this can be used as a starting point to further enhance Approvals (with or without customisation).  The methods uses a combination of the "SRM Level" field and a custom Approval process to achieve the desired results.

Further enhancements can be achieved by utilising a "lookup" form (this is shown in some of the configurations) to return the value(s) for the Approver(s) [Remedy Login IDs).


There are a number of different methods that are available in the documents section along with a large number of discussions surrounding SRM Approvals and implementing Approvals based on question responses, this is just one way of implementing a flexible methodology where complex Approvals can be achieved using OOB functionality and "Configuration over Customisation".






Describe various configurations performed on the SRM Application and the 8.1 AR System in order to facilitate Service Request Approvals that are "non-standard".


Based on the different requirements, the following types of Approval are configured:


  • Line Manager Approval – Available to be configured OOTB in the SRD
  • Approval based on user’s Question Response – the Submitter of the Service Request selects a person (via a lookup or hardcoded value), and this person’s “Login Id” is populated in a question response which is later pushed to SR Type Field 10 in the SRM:Request record
  • Level approval by Support Group Members with “Request Approver” Functional Role. This is configured in the APR:Approver Lookup form


The above Approval processes and combinations of these are used to configure Service Request Approvals across a variety of requests.


Note: The Remedy Login Id is required to be returned from a “lookup”/query/question for use with the custom Approval Process configured for SRM. This can be a single Login Id or a delimited list of Id’s separated by a semi colon (“;”).  The custom Approval Process is configured to use “One Must Sign” to move the Approval forward.




1.1    Approval Processes


The following processes are used to configure approvals on service requests


  • Service Request > Management Chain – OOTB process using one or two levels of line manager approval


  • Service Request > Level – OOTB process using APR:Approver Lookup to generate approvers


  • SRM Custom on SR Field – Custom process based on the value of “SR Type Field 10” field on the “SRM:Request” record – if the Remedy Login ID is populated in this field the approval process will assign the person with this Login ID as an Approver of the request.  The Approval configuration is found in Section 3.


1.2    Approval Chains


The above processes are used to create various Approval Chains fulfilling the different requirements for first, second and third level of Service Request Approval.


The following approval chains are defined:


  • Manager and Level Approval – Invokes the Management Chain and then Level Approval based on APR:Approval Lookup form.


  • Manager and SRField 10 Approval - Custom chain combining Manager Approval and individual approver based on the value of SR Type Field 10 in a Service Request.


  • RAS and Issue Token - Custom 3 Level Approval with Line Manager at first level, a list of users pushed to “SR Type Field 10” at second level and a Support Group defined in APR:Approval Lookup form at third level.



1.3    Approval Chain Triggers


Attaching the custom approval chains to a submitted Service Request is driven by its “Level” and “Approval Type” properties i.e. the “Approval Type” should be defined as custom:


Picture 1.png


and “Level” should be matching the levels defined below for the various chains.  This gives flexibility and reuse possibilities by utilising the “Level” field defined on the SRD.



1.3.1  Approval Chains


  • Level = Manager and Level

Picture 2.png


  • Level = Manager and SRType Field 10

Picture 3.png


  • Level = Manager-SRType10-Level

Picture 4.png

Examples of different Approval Processes for specific SRDs


2.1    SRD: Grant Internet Access to User


Requirement: Line Manager Approval




Approval Type = Manager

Max Approval Levels = 1


Picture 5.png 

2.2    SRD: Authorisation for bulk email transmission (250 User)




1st Level Approval

2nd Level Approval

3rd Level Approval

Line Manager





Configuration: It has been identified that the Director is in fact the Line Manager’s Line Manager and therefore 2 levels of Line Manager Approval have been configured.


Picture 6.png


2.3    SRD: Grant Access to a generic Mailbox (Exchange)




1st Level Approval

2nd Level Approval

3rd Level Approval

Line Manager

Generic Mailbox Owner (response of SRD question)






Level = Manager and “SRType Field 10”

Approval Type = Custom > “SR Type Field 10” mapped to the “Mailbox Owner” question which keeps a Remedy Login ID


Picture 7.png

  Picture 8.png

2.4    SRD: Increase HDrive or ShareDrive Application




1st Level Approval

2nd Level Approval

3rd Level Approval

Line Manager

Support Group: XXX > GTO - Capacity Management > Storage






Level = Manager and Level

Approval Type = Custom



Approval Mapping created in APR:Approver Lookup for the “Storage” Support Group


Picture 9.png 
Picture 10.png



2.5    SRD: Grant Access for Support Administrative rights




1st Level Approval

2nd Level Approval

3rd Level Approval

Line Manager

Support Group: XXX-> GTO - Client Server Services -> Directory Services

Support Group: XXX-> Ops Risk -> L3 - Identity Access Management





Level = Manager and Level

Approval Type = Custom



Two Approval Mapping records created with Level = 0 and Level = 1


Picture 11.png

Picture 12.png

Picture 13.png


2.6    SRD: Provide Remote Access to User




1st Level Approval

2nd Level Approval

3rd Level Approval

Line Manager

Information Security Officers – this is list of people authorized to approve. Different people are set based on the values of user inputs like “Business Area” and “Business Unit”. Also this approval level is only required for vendors and non-client owned machines.

Support Group: XXX > GTO - Client Server Services > Citrix Infrastructure





Level = Manager-SRType10-Level

Approval Type = Custom


Picture 14.png


Action is built to populate the “Approver” read only question with the relevant Login ID based on mapping which is defined in the custom form “SRD:QuestionsMenuQueryItems”.  This custom form contains “Configuration” entries that are used in Query based SRM questions.


Picture 15.png 

Approval Mapping record created for the third level approval by the Citrix Support Group


Picture 16.png



3  Custom Approval Process – SRM Custom on SR Type Field


A custom Approval Process is configured to utilise the values that are mapped from the Service Request Questions to the Service Request record in “SR Type Field 10”.

The following shows the configuration for this custom Approval Process.


Picture 17.png

Picture 18.png

Picture 19.png




Picture 20.png


Self Approval

Picture 21.png



Picture 22.png


Get Authority

Picture 23.png

Picture 24.png


Prep Get Next Approver


Picture 25.png

Picture 26.png


Get Next Approver


Picture 27.png

Picture 28.png


You can also find the above configuration in the attached documentation.


I'll be talking about this at Session 277: "Case Study: Standard Bank South Africa - Accelerating Service Request Fulfilment from Weeks to Hours" at BMC Engage 2016. Join me there to learn more.


See you @ BMC Engage 2016