SC Request and Requested Items--What are the OOB work flows and interoperability

[Danny Howell]

Our company is less than 6 months in adopting ServerNow platform (Madrid) and we are building our first Service Catalog Requests.  In our work, we are seeing OOB behavior contrary to that described by the implementation consultants and ServiceNow sales.   Training classes covered very little about SC work flows using either Workflow Editor or the new Flow Designer.  I’m turning to the community would appreciate your shared knowledge with me to understand SN out of the box process flow. 

Particularly, the following variations between what we were told and what we observed.  Most of these questions are True/False

For SC Requests (sc_requests) and Request Items (sc_req_item)

1. do not have an OOB process or workflow to add an Approver based upon the Requested By or Ordered By manager. We created requests that show this to be true
2. do not change the Approval field to “Requested” once an Approver is added and the Request Approval is sent. We created and processed requests that show this to be true
3. do not change the Approval and Request State field to respective values after the Approver makes an approval decision (Approve, Reject). We created and processed requests that show this to be true
4. do not update each/all the Request Items approval state to the same state as the Request’s approval value. We created and processed requests and requested items that show this to be true despite being told otherwise
5. Is it true that the new Flow Designer triggers for Service Catalog Application (after enabling the plugin) reference only the SC Request Items. To build work flows for Requests (sc_request) we must use either Work Flow editor OR Flow Designer using the Record (Created, Updated, Created or Updated) triggers

The interaction in a thru d indicate we need to create our own workflows not just for Request Items but also for Request processing and approval validation.  SN reps only indicated that Request Items require workflows. 

1. Can you please elaborate what is OOB and what is your best or most common practice for workflows regarding the RITM and REQ statuses for standard service catalog request?
2. b) Please mention what happens with various statuses in both REQ and RITM forms? What is the best practice of updating the approvals for each and maintaining the relationship concerning approvals between them.
3. C) Use of “self-approvals” (when the RequestedBy entity has the business authority to approve their own requests.) Most all documentation references RequestBy.Manager dotwalking (or other method) but very little on identifying an individual as a “Manager” without requiring a reference to someone or something else (ex. Just look up ‘department’ manager).  How does your organization handle this?

We are simply trying to understand the scopes at which we must design the processes, especially when told “Service Catalog works ….” by those more experienced than us and those instructions are opposite of what we see.

Thank you in advance.

[sachin_namjoshi]

Please see answers below

1. do not have an OOB process or workflow to add an Approver based upon the Requested By or Ordered By manager. We created requests that show this to be true-->this is correct.
2. do not change the Approval field to “Requested” once an Approver is added and the Request Approval is sent. We created and processed requests that show this to be true --> correct it depends on your workflow configuration. you can control RITM stage and approval stage in workflow.
3. do not change the Approval and Request State field to respective values after the Approver makes an approval decision (Approve, Reject). We created and processed requests that show this to be true --> No, you can control this behavior in your workflow
4. do not update each/all the Request Items approval state to the same state as the Request’s approval value. We created and processed requests and requested items that show this to be true despite being told otherwise --> your observation is correct.
5. Is it true that the new Flow Designer triggers for Service Catalog Application (after enabling the plugin) reference only the SC Request Items. To build work flows for Requests (sc_request) we must use either Work Flow editor OR Flow Designer using the Record (Created, Updated, Created or Updated) triggers

-->You should build workflows on sc_req_item table since one requests can have many RITM and one RITM can have many catalog tasks.( e.g onbarding new employee catalog item will involve different groups ( HR, IT team, payroll, workday etc) Flow designer separate plugin needs to be activated for service catalog.

1. Can you please elaborate what is OOB and what is your best or most common practice for workflows regarding the RITM and REQ statuses for standard service catalog request? --> It's best practice to configure workflow on sc_req_item table based on reason mentioned above.
2. b) Please mention what happens with various statuses in both REQ and RITM forms? What is the best practice of updating the approvals for each and maintaining the relationship concerning approvals between them.

-->  Your workflow drives RITM and REQ stage and status values based on your fulfillment flow configured in workflow. Approvals are prerequisite to create fulfillment catalog tasks for resolver groups.

1. C) Use of “self-approvals” (when the RequestedBy entity has the business authority to approve their own requests.) Most all documentation references RequestBy.Manager dotwalking (or other method) but very little on identifying an individual as a “Manager” without requiring a reference to someone or something else (ex. Just look up ‘department’ manager).  How does your organization handle this?

--> In our org, you should dot talk to user's manager on sys_user table since user records generally gets feed from employee records systems ( e.g AD, workday etc).Manager will be always pulled from these sources of truth for user data.

Regards,

Sachin

[Danny Howell]

Thank you for responding so quickly.  It is helpful to turn to others to 'prove I'm not crazy'.  Your response confirmed that, at least when it comes to those questions, I'm correct (and not nuts!! 🙂

[Danny Howell]

We are approaching Approvals from multiple business cases outside the person's direct manager approves all requests.

We do have several use cases where either the manager of a department or his employees submit Requests for same item in the Catalog.  example: Manager or an employee can request a new VOIP phone for their branch office.  

When we dot walk using RequestBy.Manager is rolls to the "Manager's Manager" when they the manager has approval authority for the item. 

Also, the direct manager of the RequestedBy, OrderedBy or in cases of Request on Behalf operations, may not be the person granted authority to approve a business process/item.  Example: Approve to access a database is granted by the 'data owner' which is not the same as the requester's manager.

So trying to see what other do in determining a 'manager's self approval'--We have thought of multiple ways to resolve but some have implications on some of our core table population from LDAP or other sources which we may need to implement.