Deployment and Collaboration for Agentic Workflows in ServiceNow

[prachikomal]

Hi Community,

I’m currently working with an agentic workflow in my PDI and would like to better understand how deployment and collaboration are typically handled for AI agents in ServiceNow.

Specifically, I have the following questions:

1. Deployment approach
   How are agentic workflows deployed across instances (for example, from PDI to higher environments)?
   Is Update Sets the recommended or only supported mechanism, or are there alternative deployment approaches for AI agents and related configurations?

2. UI Builder dependencies
   If an agentic workflow references a UI Builder (UIB) Experience Page or other UIB configurations, are these UI components automatically included in the Update Set?
   Are there any best practices to ensure that all UI dependencies used by the workflow are properly captured and deployed?

3. Collaboration and parallel development
   How does collaboration typically work when multiple developers are working on the same agentic workflow in parallel?
   Are there recommended practices or tooling to manage conflicts, versioning, or concurrent changes in agent definitions, prompts, workflows, and UI components?

Any guidance, best practices, or documentation references would be greatly appreciated.

TL;DR:
I’m working with an agentic workflow in a PDI and want to understand how AI agents are deployed across instances. Are Update Sets the only option? How are UI Builder dependencies handled? Also, what are the best practices for collaboration and parallel development on agentic workflows?

---

Thanks in advance!

[prachikomal]

PS: I want to understand how deployments like this work when the agentic workflows are production ready.

[yashkamde · Accepted solution]

Hello @prachikomal ,
From a deployment perspective, agentic workflows behave like most other ServiceNow configurations. You’ll usually move them via Update Sets, but only published workflows are captured. For larger projects or when you want to bundle agents, prompts, and UI Builder pages together, it’s cleaner to package them in a scoped application and push through the Application Repository. That gives you a more controlled promotion path and avoids missing pieces.

One common gotcha is UI Builder dependencies. Experience pages and related records don’t always get pulled into Update Sets automatically, so it’s best to validate those and bundle them in the same scoped app. I’ve found it helpful to keep a checklist of UIB artifacts and confirm them after migration — otherwise you risk broken references in higher environments.

For collaboration, treat agentic workflows like any other shared config: use separate Update Sets per developer, establish ownership of agents/prompts, and lean on Git/DevOps integrations for script-heavy logic. And to your PS — once you’re moving into production, the mechanics don’t change, but the emphasis shifts to evaluation and validation. Run Agentic Evaluations, confirm UI dependencies, and test thoroughly in UAT so the agent behaves consistently in live scenarios.

Best practices I’ve seen work well

• Always publish workflows before capturing them in Update Sets.
• Bundle UI Builder artifacts in scoped apps for consistency.
• Run Agentic Evaluations before moving to production — this catches issues early since AI agents can behave differently than deterministic workflows.
• Establish a branching/ownership model for collaboration to avoid overwrites.
  
  

If my reponse is helped mark as helped and accept the solution..

[Mdsaqib826]

Hi @prachikomal ,

You can migrate your Agentic AI workflows using Update Sets. this is the supported and recommended approach for moving configurations from PDI to higher environments. Ensure all related tables (agent definitions, prompts, workflows) are captured in the same Update Set as outlined in the shared article for complete deployment.

Please go through this article once for Agentic AI Tables ,

Link : Article