Development Server

integrators who have one or more dedicated production servers should obtain a dedicated development server a separate development server is ideal for a team developing assemblies and automations without fear of that development activity disrupting or inadvertently breaking production automations a single development server is able to publish content to one or more associated production servers the general workflow with a development server is like this a team of developers work on assemblies and automations using their own individual accounts a separate account on the development server is used to house the final automation templates that are tested and ready to be published to production developers either deploy automations into this separate account or "switch" into the account and edit/test the automations directly if multiple production servers exist, consider either having multiple accounts to house the production ready templates, or use folders to separate templates to know which ones are associated with which production server finished templates are published from the development server to the production server's special "templates" account see publish template to production docid\ ueps36xvj h6xmhjs nrf and the "templates" account docid\ fhjoir9rx7kx y5shd38w from the production server's special "templates" account, template automations are deployed and linked to end user accounts when linked, existing automations in end user accounts get updated with any changes made to the automations the system knows which accounts are linked to which templates, so changes can be deployed to all linked accounts at once usually, however, you will want to first test automation changes with a few certain customers first to make sure the changes are good in a live setting when the template changes are confirmed to be good, then they are deployed to all remaining linked accounts in one step see deploying automations docid\ atbvfk6y3385rnkphvbos