- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-24-2017 11:39 PM
Hi SN experts, I need help with Team Development setup, I study all possible SN docs online, and searched via WIKI, Community and here but couldn't find answer for a few things which are not clear to me. Hope to get your answers.
Here is our SN Setup:
Prod -> TEST -> DEV instances.
As our team growing we decided to try Team Development application/module to deliver our code to Prod from Dev but I am a little confused to complete the Team Development setup.
Based on the below picture from SN docs, I should be able to create multiple Sub-Dev instances/environments for each my dev but I have no idea how to do it. I feel like I am missing something here.
When I go to my Dev instance within Team Development section then so far I can only create remote instance (which is TEST) from "Team dashboard" module and then can Pull from Test make a changes then Push to Dev-Parent and it will create a local update set (that is what I got from this video: ServiceNow Team Development Demo - YouTube ) .
Please let me know if I can configure multiple Sub-Devs on my https://dev.service-now.com instance or if not then how this should be done?
Is possible to have multiple branches? ( like github has). When one task on hold i can switch to another task and complete it from another branch.
A lot of " thank you" for any advises and answers.
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2017 08:39 PM
Team Development isn't intended to work with multiple "branches" on the same instance, it's meant for multiple development instances. If you were to reproduce the diagram you showed exactly, you would have SIX instances, 4 dev, 1 test, and 1 production. You cannot create these on your own - you have to purchase these separately.
The parent dev instance would be: dev1.service-now.com
These are the individual dev instances:
Dev2.service-now.com
dev3.service-now.com
dev4.service-now.com
Test instance: test.service-now.com
Production: production.service-now.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2017 08:28 PM
In your sub-dev1/2/3, add the remote instance(dev-parent) and set the parent as "dev-parent"

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2017 08:39 PM
Team Development isn't intended to work with multiple "branches" on the same instance, it's meant for multiple development instances. If you were to reproduce the diagram you showed exactly, you would have SIX instances, 4 dev, 1 test, and 1 production. You cannot create these on your own - you have to purchase these separately.
The parent dev instance would be: dev1.service-now.com
These are the individual dev instances:
Dev2.service-now.com
dev3.service-now.com
dev4.service-now.com
Test instance: test.service-now.com
Production: production.service-now.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-25-2017 10:27 PM
Thank you Patrick for your reply. I think we might left with one option here: to have the sandbox as Sub-Dev and as long as we can't clone anything to sandbox we can try to pull-push to it and from it. But not sure how much can we push and pull maybe Pull won't be enough to get everything from Dev-Parent.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 05:10 AM
There's something to be said about keeping your different instances "clean". If you only have one development instance, then just...don't use team development. Adding a single sub-dev instance to the end of the chain isn't really going to address the same problems that multiple instances would. My group works out of a single development instance and it's just fine.
Having a sandbox environment is very useful - if you start doing actual development work there, then it ceases to be a sandbox. Consider a sandbox environment one that could get reset at any moment, and nobody would lose important work.