I need the best solution/best practice to implement the approval integration???

[Manikantahere]

Please have some time to understand and to give me some insights.

For approvals to be done I am doing approval integration between ServiceNow and Power Automate.

The Initial requirement is for 3 catalogue items when ever approval triggered(be it individual or group) I am sending corresponding approver and requestor details to power automate through rest outbound call so that they will send the notifications in the teams to approvers.

Later through Schedule Job I am getting the approval statuses back and updating them in our approval table based on the status further approvals/tasks/actions will be taken place accordingly flow logic.  For this I have Configured a sub flow for getting approver/requestor details and for making rest out bound call to power automate so that I can re use this sub flow multiple times in the same flow or in different flows as well.

Now the ask is what if it is from the normal table approval or if the approval is created from the flow script rather than with OOB ask approval action, can it be used?  So new method suggested is writing a BR on approval table to make a REST out bound call to third party?  But...BUT...

Challenges/Doubts:

1.     Is this best practice to write a BR on Approval table to make a rest outbound call?
2.     Is this good approach when it comes to catalogue items  as the logic is defined in a flow and rest calls are somewhere on the approval table??   
3.    Earlier in the sub flow  When it is a group approval  all the approver details I am sending back to power automate in a single request (To have a logic their side I am forwarding  Everyone Group or Anyone Group as one of the parameter) . But now If I implement the BR on approver table I am going to make a one REST call for every approval record created in ServiceNow? 
4. Ex If one individual approval and 2 groups approvals in the sub flow I am making only 3 calls but where as if you consider group has 5 members for the same scenario 1+5+5 total   11 calls needed ? Is this good approach?
5. To facilitate seamless integration with power automate, I am sending approval type value designated as Individual, Everyone, Anyone  to make understand power automate understand what is the sort of approval request it is so that it can mirror the ServiceNow behaviour or identical logic their side. But when I write BR on Approval table I can't send the approval type as every approval goes as single approval request to power automate. In This case for example anyone scenario the moment one person approved ServiceNow will make remaining persons no longer required so to make same approvals no longer required from power automate I need to send those details back to power automate each time when it is group approval? Is that make sense?

If someone give your inputs or best approaches It would be helpful for me to implement better solution. Thanks Advance.

[Itallo Brandão]

Hello,

It sounds like you have a fairly robust setup where you’re sending approval data to Power Automate, then receiving statuses back via a scheduled job, updating ServiceNow’s approval records. 

---

1. Subflow vs. Business Rule (BR) on Approval Table

Subflow Approach (Current Setup)

• Pros

  • Centralizes your outbound REST logic in one place, making it reusable across multiple flows or catalog items.
  • Allows you to gather all the approver details (especially for group approvals) and send them once per triggered approval event.
  • Easier to manage and debug since the subflow logic is directly tied to the overall process flow (e.g., “Ask for Approval” action).

• Cons

  • You have to ensure each flow (or action that triggers an approval) calls the subflow. This requires flow-level updates if new scenarios arise.
  • If approvals get created outside of those flows, your subflow might not automatically fire unless you incorporate it in those other processes.

Business Rule on Approval Table

• Pros

  • Will capture any approval record creation, regardless of whether it comes from an OOB “Ask for Approval” action, a scripted approval, or a standard table-based approval.
  • Reduces the need for separate subflows if your main goal is “whenever an approval record is created, call out to Power Automate.”

• Cons

  • High volume: Every approval record creation triggers an outbound REST call. For group approvals, each user record creation could generate additional calls (especially in “Everyone” or “Anyone” scenarios). This might produce a large number of API requests to Power Automate, which is both a performance and licensing concern.
  • Granularity: You lose the context that the subflow typically provides (e.g., “Anyone vs. Everyone vs. Individual”). You might have to piece logic together with multiple calls or partial data.
  • Harder to manage advanced scenarios: For example, if the first person in a group approves, you’d have to create additional logic in the BR or follow-up actions to inactivate/cancel the remaining approval records, and then do another REST call to Power Automate to reflect that change.

---

2. Group Approvals & “Anyone vs. Everyone” Logic

• In your subflow approach, you’re sending the entire list of potential approvers in one call, along with a parameter that clarifies “Anyone,” “Everyone,” or “Individual.” This helps keep the logic straightforward on the Power Automate side, since they can handle the group logic in one go.
• If you move to a Business Rule that fires on each approval record:
  • You’d likely lose the single-call advantage. A group approval that expands to 5 members might generate 5 separate calls.
  • You’d need more complex logic to handle real-time updates whenever one person in a group approves (especially in “Anyone” scenarios). Potentially it could lead to repeated calls to “cancel” or “inactivate” the other approvals.

Conclusion: If group approvals are common and the difference between “Anyone,” “Everyone,” or “Individual” matters, calling from a single subflow is often more maintainable and keeps API calls lower.

---

3. Best Practices

1. Limit High-Volume Calls

   • If a single group approval leads to multiple user approvals, do you really need to call out individually for each user record? If not, the subflow approach is probably more efficient—aggregate the user records and send one payload.

2. Maintain Context

   • Approvals in ServiceNow might rely on the “Stage” logic (Approved, Rejected, No Longer Required). If you do a per-record approach, you’ll need robust logic in both ServiceNow and Power Automate to keep them in sync, especially in “Anyone” scenarios.

3. Versioning & Reusability

   • Subflows are easy to version-control, debug, and reuse. If new requirements appear (e.g., new catalog items, scripted approvals), you can ensure they also call the same subflow.
   • A broad Business Rule on the Approval table might inadvertently catch other approvals that don’t need to be integrated with Power Automate.

4. Performance & Scalability

   • Sending multiple calls for every single approval record can become a bottleneck. Evaluate how many approval records you typically create and how that might scale over time.
   • Use Performance Analytics or basic reporting to see how many approval records are created daily/weekly in your environment, especially with group approvals.

5. Modular Flow Logic

   • If you keep your subflow logic modular, you can design it to handle both typical “Ask for Approval” scenarios and scripted approvals. That way, you don’t need a BR on the table. You can simply ensure that all approvals go through the subflow.

---

4. Suggested Approach

• Stick with Subflows if possible, because you:

  • Control the logic centrally (i.e., how to handle group approvals, sending a single REST call, etc.).
  • Can keep the existing approach for the 3 catalog items, and for new normal-table approvals, incorporate the subflow script logic so it’s reused.

• Use a Targeted BR only if there is truly no single flow or subflow that can capture all approval creation scenarios. If you do a BR:

  • Consider a filter or condition that only triggers the REST call for certain records or certain use cases.
  • Add robust logic to manage group expansions and real-time updates so you don’t spam Power Automate with unnecessary calls.

---

Summary
From a best-practice standpoint, it’s generally cleaner and more efficient to keep your REST outbound calls in a subflow or Flow Designer logic—especially for group approvals—rather than a catch-all Business Rule on the Approval table. The subflow method allows you to send a single consolidated message to Power Automate per approval request, preserving the context of “Anyone/Everyone/Individual” and reducing the volume of calls.

I hope these insights help you design a better solution. Let us know what path you decide on and if you have further questions about implementation details.

Best regards,
Itallo Brandão

[Manikantahere]

Thanks for your response.

In my case  I am not doing for all the approvals as of now and need to implement only for specific approvals. So sub flow approach is pretty much good in scenario however from the business rule I can have the conditions based on the item name but how to restrict for normal tables specifically?

The Question I got back when I am implementing sub flow approach is if we call sub flow in say for ex 50 flows and consider If we get rid of  this integration need to edit back all the flows. If think in this prospective is this good to go?

[Itallo Brandão]

Hi again,

If you need to integrate only specific approvals (e.g., certain catalog items) with Power Automate, here’s a practical approach:

1. Keep It in a Subflow (or a Custom Flow Action)

   • Rather than using a broad Business Rule on the Approval table, configure your flow to call a subflow whenever approvals match a certain condition (e.g., an item name or source table). This ensures you only integrate the approvals you want.
   • If you put your REST logic directly in 50 flows, removing the integration later would be cumbersome. Instead, maintain a single subflow or “wrapper” Flow action that does the REST call.

2. Use a System Property

   • Add a property (e.g., glide.property.power_automate_integration_enabled) in your subflow. If it’s set to true, the subflow calls Power Automate. If you ever need to disable or remove integration, just flip it to false.
   • This way, you don’t have to edit every flow. All 50 flows keep calling the same subflow, but the subflow itself won’t execute the outbound REST call if the property is turned off.

3. Benefits

   • Selective Triggers: Only send data to Power Automate for the approvals or items that matter.
   • Centralized Logic: Avoid multiple “copies” of the same integration steps.
   • Easy Maintenance: If you decide to drop the integration, you simply modify or deactivate the subflow/action or update the property, rather than touching all flows individually.

Hope this helps you implement a more efficient, flexible solution. Let us know if you have any further questions!

Best regards,
Itallo Brandão