Placeholder within Approval Group Name

Not being able to use dynamic placeholders for approval group names forces unnecessary API calls, which adds latency and complexity to workflows. Having to chain multiple GETs and then a PUT/POST just to handle something that could be resolved inline is definitely not efficient.

A placeholder-based approach would streamline the process, reduce API load, and significantly improve performance  especially for larger or more complex automations.

Really hope this gets considered, as it would make a noticeable difference in real-world use cases.

MrJohn, don’t forget to upvote. Thanks for your input!!! I’m glad I’m not alone.

Would love to see this feature. Currently I’m just using generic approval group names but it would be great to use placeholders here.

I completely agree with this request. The lack of placeholder support inside the approval group action node creates unnecessary workflow complexity and extra API overhead for something that should ideally be handled natively within the automation layer.

Having to chain multiple GET requests just to dynamically resolve approval group names before a PUT/POST operation adds latency, increases maintenance effort, and makes flows harder to scale and troubleshoot. Placeholder support would significantly simplify automation design while also reducing API consumption and execution time for larger environments.

Upvoted!

Chaining webhooks and API calls just to dynamically name approval groups is such a headache, especially once you start running into daily API rate limits on larger instances. Having native placeholders like {{ticket.department}} or requester custom fields right inside that action node would clean up so much workflow clutter. Really hope the product team picks this up soon.

Upvoted. Native placeholders in the Approval Group Name field would remove a lot of unnecessary workflow steps. Being able to pull values directly from ticket fields or custom objects would make these automations much cleaner and reduce the extra API calls. Hopefully this gets added soon.

yes, we need this. Approval in loops just get named “base name” ...1 ...2 ...3. 
using a CO to keep track of the name. But still the action isn’t that dynamic. 

You can’t use requester groups or agent groups directly. 

Using a placeholder within an approval group name could be useful for workflows that need dynamic or context-specific naming. It would be helpful to clarify which placeholders are supported, when they are resolved, and whether the generated group name is displayed consistently across approval notifications and workflow records.

Using a placeholder within an approval group name could be useful when approval workflows need dynamic or context-specific naming. It would be helpful to know which placeholders are supported, when they are resolved, and whether the generated group name remains consistent across notifications and workflow records.

I can see why this would be useful. Being able to use placeholders directly in the approval group name would remove several extra API calls and make the workflow much more efficient, especially when the group name depends on custom object data. The Golf Prints custom print

I can see why this would be frustrating having to make several extra API calls just to populate an approval group name adds unnecessary complexity. Supporting placeholders directly in the action node would definitely simplify the workflow and reduce the number of requests needed.cheap car rental Auckland