Team Development

Team Development in ServiceNow

Team Development in ServiceNow

Why is Team Development Important?

In enterprise environments, ServiceNow development rarely happens in isolation. Multiple developers, administrators, and teams often work on customizations, configurations, and applications simultaneously. Without a structured approach to managing changes across instances, organizations face significant risks including:

- Overwritten changes: One developer's work could be accidentally replaced by another's
- Inconsistent environments: Production, development, and testing instances can drift apart
- Deployment failures: Moving changes between instances without proper tracking leads to errors
- Lack of accountability: Without version tracking, it becomes difficult to know who changed what and when

Team Development solves these challenges by providing a framework for managing and synchronizing changes across multiple ServiceNow instances in a controlled, auditable manner.

What is Team Development?

Team Development is a built-in ServiceNow feature that enables multiple developers to work on the same application or instance configuration simultaneously by using a parent-child instance model. It provides tools to:

- Track changes (referred to as Local Changes) made in each instance
- Compare versions of records across instances
- Push changes from child (development) instances to a parent instance
- Pull changes from the parent instance down to child instances
- Detect and resolve collision conflicts when the same record has been modified in multiple instances

Team Development is particularly relevant in organizations that use multiple development or sub-production instances where several teams or developers are making changes in parallel before promoting those changes upstream toward production.

Key Terminology

- Parent Instance: The central or upstream instance that serves as the authoritative source. Changes from child instances are pushed up to the parent. This is often a consolidated development or integration instance.
- Child Instance: A downstream development instance where individual developers or teams work. Each child instance is linked to a parent instance.
- Local Changes: Records that have been created, modified, or deleted in a specific instance. These are tracked automatically by Team Development and represent the pool of changes available to push or pull.
- Remote Changes: Changes that exist on the parent instance that are not yet present on the child instance.
- Collision: A conflict that occurs when the same record has been modified on both the parent and child instances. Collisions must be resolved before changes can be committed.
- Push: The act of sending local changes from a child instance to the parent instance.
- Pull: The act of retrieving remote changes from the parent instance to a child instance.
- Code Review: An optional step where pushed changes can be reviewed before being committed to the parent instance.

How Does Team Development Work?

1. Setting Up the Parent-Child Relationship

An administrator configures the parent-child instance relationship through Team Development > Instance Setup. The child instance registers with the parent using credentials and URL information. Once connected, the instances can communicate and compare records.

2. Tracking Local Changes

When a developer modifies a record (e.g., a Business Rule, UI Policy, Script Include, or any configuration record) on a child instance, Team Development automatically logs this as a Local Change. The system tracks:
- The record that changed
- The type of change (insert, update, delete)
- The user who made the change
- The timestamp of the change

3. Comparing Instances

Before pushing or pulling changes, developers can compare their local changes with the state of the parent instance. This comparison identifies:
- Records that exist locally but not on the parent
- Records that have been modified locally
- Records that are in conflict (collisions)

4. Pushing Changes to the Parent

When a developer is ready to promote their work, they select the relevant local changes and initiate a push to the parent instance. The process involves:
- Selecting changes from the Local Changes list
- Reviewing and resolving any collisions
- Committing the changes to the parent

If code review is enabled, the changes go into a review queue on the parent instance where a lead developer or administrator can approve or reject them before they are committed.

5. Pulling Changes from the Parent

To stay synchronized, developers on child instances periodically pull remote changes from the parent. This ensures they have the latest versions of records that other teams may have pushed. Pulling helps minimize future collisions.

6. Resolving Collisions

Collisions occur when the same record has been modified on both parent and child instances. When a collision is detected, the developer must choose one of the following resolutions:
- Accept Local: Keep the child instance version and overwrite the parent
- Accept Remote: Keep the parent instance version and discard the local change
- Manual Merge: Manually review and combine changes from both versions

Collision resolution is a critical skill and a common exam topic.

7. Using Update Sets vs. Team Development

It is important to understand the distinction:
- Update Sets are used to move changes between instances in a serial, batch fashion (e.g., from Dev to Test to Prod). They capture changes in a transportable container.
- Team Development is used to manage parallel development across multiple child instances that share a common parent. It operates alongside update sets but focuses on synchronization and conflict resolution rather than promotion.

In practice, Team Development is used during the development phase when multiple developers are working in parallel, while Update Sets are used for the formal promotion pipeline (Dev → Test → Prod).

Best Practices for Team Development

- Pull frequently: Regularly pull remote changes from the parent to minimize collisions
- Push small, incremental changes: Avoid accumulating large numbers of local changes before pushing
- Enable code reviews: Use the code review feature for quality control on the parent instance
- Communicate with your team: Coordinate who is working on what to reduce conflicts
- Resolve collisions promptly: Do not let collisions accumulate, as they become harder to resolve over time
- Use naming conventions: Clearly label changes and update sets for traceability

Common Scenarios in Exam Questions

1. Two developers modify the same Business Rule on separate child instances and both try to push to the parent. — This results in a collision on the parent. The second push will detect the conflict, and the developer must resolve it.

2. A developer needs the latest changes from the parent before starting new work. — They should perform a pull from the parent instance.

3. An organization wants to ensure quality before changes are applied to the parent. — They should enable code reviews in Team Development.

4. What is the relationship model? — Team Development uses a parent-child instance hierarchy.

---

Exam Tips: Answering Questions on Team Development

1. Know the parent-child model: The exam frequently tests your understanding that Team Development uses a parent-child architecture. The parent is the central instance; children are development instances. Remember that changes flow up (push) and down (pull).

2. Understand push vs. pull: Push sends local changes TO the parent. Pull retrieves remote changes FROM the parent. If a question asks how a developer gets the latest changes, the answer is pull. If a question asks how a developer promotes their work, the answer is push.

3. Collision resolution is a key topic: Expect at least one question about what happens when two developers modify the same record. Know the three resolution options: accept local, accept remote, or manual merge.

4. Differentiate from Update Sets: A common trap question confuses Team Development with Update Sets. Remember: Team Development = parallel development synchronization. Update Sets = batch change promotion between environments. They are complementary, not interchangeable.

5. Code Review feature: Know that code review is an optional feature that can be enabled to add an approval step before changes are committed on the parent instance.

6. Local Changes tracking: Understand that local changes are tracked automatically. Developers do not need to manually register changes — the system captures them as they occur.

7. Read questions carefully for keywords: Words like synchronize, parallel development, multiple developers, and conflict resolution are strong indicators that the question is about Team Development. Words like migrate, promote, transport, and batch typically point to Update Sets.

8. Eliminate wrong answers: If an answer choice mentions cloning or branching (Git-like concepts), it is likely not the correct answer for a Team Development question. ServiceNow Team Development does not use Git-style branching — it uses the parent-child push/pull model.

9. Remember the navigation path: Questions may reference where to find Team Development in the platform. The module is located under Team Development in the application navigator, with sub-modules for Local Changes, Remote Changes, Instance Setup, and Code Review.

10. Practice scenario-based thinking: The CAD exam often presents real-world scenarios. Practice mapping scenarios to the correct Team Development action. Ask yourself: Who is making changes? Where are they making them? What needs to happen next? This will help you select the right answer with confidence.