Change Sets

A Change Set is a story-level tracking unit in tSM. It captures the exact set of configuration changes made for a single user story or task, giving teams visibility into what changed and a clear scope for review.

While Configuration Packages define long-lived, capability-oriented release boundaries, a Change Set provides a lighter-weight grouping that tracks individual stories within those packages.

Concept	Role
ConfigType	Ownership and taxonomy — where configuration belongs.
Configuration Package	Long-lived deployable capability — what is released.
Change Set	Story-level tracking unit — what changed for this story.
Installed Package	Operational history — what is installed in a target environment.

See also:

• Configuration Explorer
• ConfigType
• Installed Package
• Configuration Lifecycle

---

Why Change Sets exist

Configuration Packages work well when a release maps to a single capability boundary. In practice, this model has a gap:

• A user story often touches items across multiple ConfigTypes or even multiple packages.
• Several stories may be developed in parallel against the same shared package.
• Teams need to see which changes belong to which story.

Without Change Sets, there is no record of which configuration changes belong together. Change Sets close this gap by providing a story-scoped grouping on top of the existing package model.

---

Core idea

A Change Set is not a replacement for packages. It is a tracking layer that:

1. collects the exact entities touched by a story
2. provides a clear scope for review
3. records the baseline state of each entity at the time the Change Set was opened

After the story is complete and reviewed, the Change Set is closed. The entities remain part of their Configuration Packages as before.

---

Change Set lifecycle

OPEN  →  IN_REVIEW  →  CLOSED
IN_REVIEW  →  OPEN  (reopen)
OPEN or IN_REVIEW   →  ABANDONED

State	Meaning
OPEN	Active. Changes are tracked.
IN_REVIEW	Submitted for review. Changes are no longer tracked until it is reopened.
CLOSED	Review is complete. Change Set is archived for audit.
ABANDONED	Work was stopped. The items are kept.

• Submit for review is available for an open Change Set.
• Reopen returns an in-review Change Set to open, so that changes are tracked into it again.
• Close and Abandon are available for an open or in-review Change Set.
• Editing a Change Set does not change its state.

---

What a Change Set contains

ChangeSet (attributes)

Field	Type	Description
id	UUID	Internal identifier.
code	String	Short identifier, typically matching the story or ticket (e.g. US-1234).
name	String	Human-readable description.
status	Enum	Current lifecycle state (OPEN, IN_REVIEW, CLOSED, ABANDONED).
branch	String	Git branch or workspace this Change Set belongs to.
ownerUserId	String	The developer who owns the Change Set.
ownerUserGroup	String	User group that owns the Change Set.
items	List<ChangeSetItem>	The configuration entities included in the Change Set.
createdAt	DateTime	When the Change Set was created.
notes	String	Free-text notes (e.g. story description, release notes).

ChangeSetItem

Each item in a Change Set references one configuration entity:

Field	Type	Description
entityType	String	Entity type (e.g. Form, Process, Script).
entityId	String	Entity identifier.
code	String	Human-friendly entity code.
configType	String	ConfigType code of the entity.
changeType	Enum	ADDED, MODIFIED, or REMOVED (shown as Created, Updated, Deleted).
baseVersion	DateTime	Timestamp of the entity state when the Change Set was opened.

---

How entities enter a Change Set

Automatic tracking

While a Change Set is active, every configuration entity you create, update, or delete is recorded in it.

• Only configuration entities are tracked — the entities shown in the Configuration Explorer. For example, a register and its values are tracked, an order is not.
• Changes are tracked only while the Change Set is OPEN.
• Each entity appears in a Change Set only once. Repeated changes are merged:

Recorded change	New change	Result
Created	Updated	Created
Created	Deleted	The item is removed.
Updated	Deleted	Deleted
Deleted	Created	Updated

Manual changes

You can also add or remove items manually — in the Configuration Explorer (Add to Change Set, Remove from Change Set) or with the CLI (tsm changeset add, tsm changeset remove). This is useful when:

• an entity needs to be included for consistency but was not directly modified
• the developer wants to explicitly control the scope before review

---

Active Change Set

The Change Set switcher next to your avatar in the top bar decides where your changes are tracked:

• Main — no Change Set. Changes are not tracked.
• My Change Sets and Shared with me — open Change Sets you may use. Each shows its number of items; click it to open the Change Set.
• Create Change Set and Show all Change Sets at the bottom.

Your choice applies to all browser tabs and is cleared when you log out. A new Change Set is not activated automatically — select it in the switcher.

If the active Change Set can no longer be used (it was deleted, is no longer open, or your access was removed), tSM switches you back to Main and tells you why.

While a Change Set is active, opening a configuration record that is already in an open or in-review Change Set shows a message that names the Change Sets it is in by code and name: the current Change Set, the other Change Sets, or both. This helps you avoid changing the same record in two Change Sets.

---

Managing Change Sets

Change Sets are managed under Settings → Change Sets.

List

The list shows your Change Sets and those shared with you. Select several rows to Submit for review, Reopen, Close, Abandon, or Delete them at once. Change Sets in a state that does not allow the action are skipped, and a summary is shown.

The Sharing column shows whether a Change Set is shared publicly and with how many users and groups. The list can be filtered by status.

Detail

• Detail, Description, People, and Dates cards.
• Items tab — the tracked entities with entity type, code, configuration type, change type, author, and last edit. Double-click an item to open the entity.
• Comments, Attachments, and Audit tabs. Audit shows the history of changes to the Change Set.
• Actions: Show in Explorer, Share, Submit for review, Reopen, Close, Abandon, Delete.

Sharing

A new Change Set is visible only to its owner. The owner can share it with users, user groups, or publicly with everyone:

Sharing type	Allows
Read	Activate the Change Set and track changes into it.
Edit	Also edit the Change Set and change its state.

A public sharing applies to every user: others see the Change Set in the list and, while it is open, under Shared with me. Sharing types other than Read and Edit do not let anyone open, activate, or edit a Change Set.

Only the owner can share a Change Set. Only the owner or an administrator can delete it.

Privileges

Privilege	Allows
Config.ChangeSet.ViewList	The Change Sets menu and list.
Config.ChangeSet.View	The Change Set detail.
Config.ChangeSet.Add	Creating a Change Set.
Config.ChangeSet.Edit	Editing, submitting, reopening, closing, and abandoning.
Config.ChangeSet.Delete	Deleting.
Config.ChangeSet.Use	Activating a Change Set, adding and removing items.
Config.ChangeSet.Share	Sharing.
Config.ChangeSet.ViewAll	Seeing all Change Sets.
Config.ChangeSet.Manage	Administrator: seeing, editing, changing the state of, and deleting any Change Set. It does not allow tracking changes into someone else's Change Set.
Toolbar.ChangeSet	The switcher in the top bar.

New privileges are not assigned to any role automatically.

---

Relationship to existing concepts

ConfigType

ConfigType still defines where every entity belongs. Change Sets do not alter ConfigType assignment. They use ConfigType for:

• filtering and displaying Change Set contents
• validating that entities have correct ownership

Configuration Packages

Packages remain the stable, long-lived deployment boundary. Change Sets provide a story-level view within that boundary. After a Change Set is closed, the entities are still tracked under their normal Configuration Package.

Installed Packages

Change Sets are independent of deployment. Deployment is handled through the normal package deployment pipeline. The installSource on an Installed Package may indicate the originating Change Set for traceability.

---

Configuration Explorer integration

• The Change Set column shows the open, in-review, and closed Change Sets of each item with its change type. Abandoned and deleted Change Sets are not shown.
• A deleted entity is shown, marked as deleted, when you filter or highlight by a Change Set that tracks it, a closed one included. The Change Set column keeps the change type each Change Set recorded, so an entity deleted outside that Change Set stays Created or Updated there. An abandoned Change Set no longer shows it.
• Filter the Change Set column to see the items of selected Change Sets, including deleted ones.
• Show in Explorer on a Change Set opens the Explorer filtered to that Change Set.

The tree can also follow the active Change Set or only highlight its items. See Configuration Explorer.

---

CLI

Change Sets can also be managed from the command line. For details, see tSM CLI.

---

Example: two stories in parallel

Two developers work on independent stories in the same project:

Story	Developer	Change Set
US-1234	Bob	US-1234
US-5678	Alice	US-5678

Bob modifies forms and processes in the SDWAN package. Alice modifies registers and scripts in BSSBase.

Both work in parallel with their respective Change Sets active in the UI.

When Bob finishes:

1. Bob submits US-1234 for review (OPEN → IN_REVIEW).
2. Reviewer inspects the tracked items and confirms the scope is correct.
3. US-1234 is closed (IN_REVIEW → CLOSED).
4. The SDWAN package is released and installed through the normal deployment pipeline.

When Alice finishes:

1. Alice submits US-5678 for review.
2. Review is complete.
3. US-5678 is closed.
4. The BSSBase package is released and installed.

Both stories are tracked independently. The Change Sets provide a clear audit trail of which entities were changed for each story.

---

Best practices

Keep Change Sets small

A Change Set should ideally map to a single user story or task. Small Change Sets are easier to review and provide clearer audit trails.

Use automatic tracking

Prefer automatic tracking over manual entity management. Select the active Change Set in the UI and let the system capture exactly what changed.

Do not bypass packages

Change Sets do not replace Configuration Packages. Every entity still belongs to a package via ConfigType and area mapping. Change Sets add story-level tracking on top.

Review before closing

Use the IN_REVIEW state to coordinate review across team members before closing the Change Set. This ensures all relevant changes are captured and reviewed.

---

Summary

Change Sets add story-level tracking to the tSM configuration model:

• Users select an active Change Set in the UI and changes are tracked automatically.
• Each story has its own Change Set with explicit entity references and baseline timestamps.
• The lifecycle is simple: OPEN → IN_REVIEW → CLOSED, or ABANDONED.
• Deployment continues through the normal Configuration Package pipeline.
• Change Sets provide an audit trail of which entities were changed for each story.

The result is clear visibility into parallel work without adding complexity to the deployment model. Packages remain capability-oriented. Change Sets handle story-level granularity.