To whom service request approvals are sent and how does it works.
There is a settings in Admin-Self Service Portal Settings to choose restriction type while sending request approval emails.
SSP configuration "Choose restriction type to be made while sending Request approval mails" has the below options.
In our current behavior, there are four ways to add an approver for a service request.
1) Using submit for approval.
2) Using template workflow.
3) Using the "Select Approvers" field.
4) Using custom triggers.
Using submit for approval:
Here we list the user list based on the SSP configuration.
If anyone can approve is configured, we can send mail to the user who doesn't even in the application.
If the system users only configured, then list all the users available in the system irrespective of the service approver role.
If Service approver only is configured, then lists the user who has the service approver role.
Using template workflow:
Using workflow you can set predefined approver for stage 1 to 5. Here we can configure the approver as an organization role or a user with "Service Approver role".
Using the "Select Approvers" field.
This one is also the same as above. We only allow organization role and user with "Service Approver role".
Using Custom trigger:
In the custom trigger, we can configure either user(Email-id) or organization role to be added as an approver. But the approval addition is based on the SSP configuration. Say for example if "Service approver only" is configured and adding approver who doesn't have the approver role, then it will skip in the approval additional and the same will be captured in the history.
Note: The SSP option will be applied for the organization role also. We are using the organization role in Workflow, Select Approver field, and Custom trigger. Adding approver with organization role, after resolving the organization role into the exact user we apply the SSP configuration on the user if it failed then we skip the approver addition and capture the same in the history.
So the service approver role is skipped when the SSP configuration is set as "Anyone can approve" or "System users only can approve".
If "Service Request approvers only can approve" is configured then it will allow the user as an approver only when the user has the service approver role.
Lets see in detail how it works:
- Anyone can approve. (To send approval even though the user does not exist in application)
- System users only can approve. (To send approval even though the user doesn't have the service approver role)
- Service Request approvers only can approve. (Only send when the user has the service approver role)
In our current behavior, there are four ways to add an approver for a service request.
1) Using submit for approval.
2) Using template workflow.
3) Using the "Select Approvers" field.
4) Using custom triggers.
Using submit for approval:
Here we list the user list based on the SSP configuration.
If anyone can approve is configured, we can send mail to the user who doesn't even in the application.
If the system users only configured, then list all the users available in the system irrespective of the service approver role.
If Service approver only is configured, then lists the user who has the service approver role.
Using template workflow:
Using workflow you can set predefined approver for stage 1 to 5. Here we can configure the approver as an organization role or a user with "Service Approver role".
Using the "Select Approvers" field.
This one is also the same as above. We only allow organization role and user with "Service Approver role".
Using Custom trigger:
In the custom trigger, we can configure either user(Email-id) or organization role to be added as an approver. But the approval addition is based on the SSP configuration. Say for example if "Service approver only" is configured and adding approver who doesn't have the approver role, then it will skip in the approval additional and the same will be captured in the history.
Note: The SSP option will be applied for the organization role also. We are using the organization role in Workflow, Select Approver field, and Custom trigger. Adding approver with organization role, after resolving the organization role into the exact user we apply the SSP configuration on the user if it failed then we skip the approver addition and capture the same in the history.
So the service approver role is skipped when the SSP configuration is set as "Anyone can approve" or "System users only can approve".
If "Service Request approvers only can approve" is configured then it will allow the user as an approver only when the user has the service approver role.
New to ADSelfService Plus?
Related Articles
Convert Incident to Service Request
For builds before 10536 The option will be available at: open the respective request > Actions > Convert incident to service request For builds after 10600. Edit the respective request > click on the Template dropdown [top-right corner] > Choose the ...To make SLA mandatory while creating a service request
The steps mentioned below make the SLA selection mandatory for any service request creation. Tested in builds : 14000 and 14301. Script: if(!jQuery("#servicesla-selected").attr("data-association-id") || ...Service request approvers
This report helps to find the who all the service request approvers in the application. SELECT aaauser.first_name "Approver Name", dpt.deptname "Department", sdo.name "Site", sd.jobtitle "Job Title" FROM srapproverdetails LEFT JOIN aaauser ON ...Automatically close request after successive approval reminders.
This post describes the use of a python script to close requests after successive approval reminders using Custom Schedules. Use Case: We have an option under the self-service portal in order to send reminders mail for the approvals, what would be ...Set SLA automatically for a service request using FAFR
Note: The below FAFR script will work only on 10600 MSP and above Requirement: Set SLA automatically for a service request depending on the Priority. Usecase: Let us consider a scenario where SLA has to be set depending on the requester's associated ...