Email notifications for Technicans - Requests
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11 hours ago
I would like to create an email notification to technicians that has the RITM in the body of the email.
Things to know:
- Only technicians create requests
- Request created from Service Catalog > Requests does not give us the option to add who the request is for, and subsequently the email comes through with the name of the technician that created the request. We would like the option to add the "requested for" field in the Requests form so the request does not come through as being requested by the technician.
- Request created from Service Operations Workspace does give us the option to create the request for a specific user, so that it does not come through as requested by the technician but as the user who requested the item.
Email will look like this:
A request has been opened by: ${requested_for}
Description: (here the description will be the RITM)
Please view the request here: ${URI_REF}
Other details.
When I create the request from Service Operations Workspace, it does not ask for the RITM or any variables added into the catalog item. You can only add a short description. It does allow you to select requested user. When creating the request from Service Catalog>Requests, it does add the RITM and lets you select a variable. It does not allow you to add the user requesting the service.
I'm not sure why these 2 ways of creating requests are different but having them match would be ideal for my team.
Thank you for any help you can provide me!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11 hours ago
Hi there @TALENAJ
For the notification, I'd recommend triggering it from sc_req_item (RITM) instead of sc_request. That will make it easier to include ${requested_for}, the catalog item details, and any variables entered on the request.
If your technicians need to create requests on behalf of users and still capture catalog variables, adding a Requested For variable (or variable set) to the catalog item is probably the cleanest approach.
One question: is your notification currently running on sc_request or sc_req_item?
Kind Regards,
Azar
Serivenow Rising Star ⭐
Developer @ KPMG.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
8 hours ago
I have set the Table as sc_req_item however I cannot find the HTML that will include the RITM in the email.
A request has been opened by: ${requested_for}
Description: (here the description will be the RITM) --need HTML code for this
Please view the request here: ${URI_REF}
When using the Service Operation Workspace can select the "Requested For" but not the Item the user is requesting.
When using Service Catalog>Requests I can select the Item but not "Requested For". Both ways of entering requests I will need both options Requested for and Item.
Having both options will then send the email to the technician with the correct "Requested For" and the requested Item. Currently I'm not able to send the request with the RITM in it since I don't have the code for it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
7 hours ago
Hi @TALENAJ
1.
When technicians create requests through Service Catalog > Requests, they are interacting directly with the Request (sc_request) table. To make the Requested for field available on the form, follow these steps:
- Navigate to Service Catalog > Requests and open any existing Request (REQ) record.
- Right-click the form header and select Configure > Form Layout.
- In the Available list on the left, locate Requested for and select it.
- Click the Right Arrow (>) to move the field to the Selected list.
- Use the Up and Down buttons to position the field appropriately on the form, ideally near the top.
- Click Save.
Once saved, technicians will be able to specify the end user by populating the sc_request.requested_for field when creating requests manually
2. By default, data from the sc_request record cascades down to its associated records.
However, if newly created RITM (sc_req_item) records do not immediately inherit the Requested for value during manual request creation, you can address this by creating a simple Before Insert Business Rule on the sc_req_item table.
Condition:
current.request.requested_for != ''Script:
current.requested_for = current.request.requested_for;
3. The notification should be configured on the Requested Item (sc_req_item) table. This approach enables you to use dot-walking to access fields on the parent Request (sc_request) record, including the user who created the request.
By referencing the parent Request record, you can accurately determine the request creator and apply the appropriate notification logic.
Regards
Tanushree Maiti
ServiceNow Technical Architect
LinkedIn: https://www.linkedin.com/in/tanushreemaiti