Assess Alternatives in Flow

[Mark Brogna]

I am working on a catalog request for new software. Part of the process (flow) tries to assess whether an alternative software in the software product model table exists that may fulfill the same need. This will be a manual assessment (3.4 in below diagram). However, at the end the 'requested for' user needs to either accept or reject the alternative software (3.5 in below diagram).  How would you handle the assessment (3.4) for the alternative application (i.e. task, approval, other???) and the end user's need to either approve or reject (3.5) the alternative?

[Udayrathore049]

For Step 3.4 — "Alternative App Available?"

Assessment Mechanism:
→ I would create a Task (most likely a Catalog Task or Requested Item Task) assigned to the Software Asset Manager or an appropriate team who can:

• Review the original software request.

• Manually check the Software Product Model table or other records.

• Suggest an alternative software if available.

Task Design Tip:
Include fields like:

• "Alternative Software Found?" (Yes/No)

• "Suggested Alternative Application" (Reference field to Software Product Model)

This keeps the assessment manual but structured, auditable, and manageable within ServiceNow.

---

 For Step 3.5 — "Does the Requestor Accept It?"

End-User Acceptance Mechanism:
→ After the task in 3.4 is completed with an alternative, I would trigger an Approval (specifically an Approval - User record) assigned to the Requested For user.

In the approval:

• Approval Text: Mention "An alternative software [Name] has been suggested. Do you accept this alternative?"

• If Approved → Continue fulfillment with the alternative application.

• If Rejected → Either:

  • Escalate to manager for decision,

  • Revert to sourcing original software,

  • Or close with "Request Canceled by User" (depending on your business rules).

[Mark Brogna]

would the workflow approval (3.5) be at the ritm level or the catalog task (3.4) level? Further, approvals don't have text associate to them. If I am attaching at the ritm level how do I pass the data from 3.4 to the task to the approval?

[KevinWhite]

Good question and I like Uday's recommendation. My thoughts on this are...

The approval would be at the RITM level because the approval is for the requester to approve a fulfillment approach for their requested item, and requester typically don't see the SCTASK details.

The fields would be variables on the catalog item that are only visible once the item is submitted. The variables would be visible on the RITM and SCTASK. In your flow, check the Alternative Software Found? variable to determine if step 3.5 is needed.

For approvals, the Approval Reason field could be populated asking for approval to substitute the alternative software for the requested software. Unfortunately, this field isn't available in the portal Approval Info widget. You could modify the widget to show approval reason. It's probably better to just the same approval reason text as a comment. Sending approvals may require an approver license for the requester.

An alternative approach might be to have the people fulfilling the task send the requester Additional Comments from the RITM asking them to agree to the alternative software. The requester would just reply to the comments with a comment accepting or rejecting the alternative. The fulfiller would could record the requester's decision in a variable Requester accepted alternative.

Hope some of this was helpful.

[Bidduam]

Hi @Mark Brogna 

We actually do something very similarly ourselves. The way we handle it is simply in a sc_task.

The sc_task is passed to a team to make an assessment if the functionality being requested is available in an application that we already have.

The SC_task simply has a question variable only shown at the task level when assigned to that team that asks if there is already other software:

If the customer accepts the other software ultimately the flow will close (you could be clever and make it request the software for the user if you wanted from there, but we make them request it separately)

If they so no they don't want to use it, then it progresses for further consultation to other teams.