Change attributes | Atomicwork

Change attributes define the information captured throughout the lifecycle of a change request. They include common attributes like Subject, Requester, and Priority, as well as custom attributes that are unique to specific templates. Each attribute can have its own visibility, editability, and validation rules.

Together, they ensure that all the necessary information is captured for each change, leading to more efficient workflows and better record-keeping.

Attributes appear in multiple places:

When creating or updating a change request
In change templates (to standardize information collection)
Within workflows (for automation or condition logic)
As placeholders in notifications and messages

To learn more about how change templates can be customized, see customizing change templates.

Common attributes

Atomicwork includes a predefined set of common attributes that are shared across all change templates. These cover the basic details needed to record, track, and manage a change request.

Attribute name	Description
Subject	The title of the change. Required for all change requests.
Description	A brief explanation of what the change involves and why it’s being implemented.
Requester	The employee or workspace member the change is for, or the person initiating the change.
Tags	Labels to categorize changes for easier search and reporting.
Group	The group responsible for managing the change.
Agent	The individual assigned to execute or coordinate the change.
Change type	Specifies whether the change is a Standard, Normal, or Emergency. Required by default in all templates.
Status	Indicates the current stage of the change lifecycle (e.g., Draft, Scheduled, Closed).
Priority	Reflects the urgency and business impact of the change, used to determine handling order.
Urgency	Captures how soon the change needs to be implemented.
Impact	Describes the potential scope or business impact of the change.
Planned start date	The scheduled date and time for the change to begin.
Planned end date	The scheduled completion date and time for the change.
Actual start date	The actual date and time the change began implementation.
Actual end date	The actual date and time the change was completed or closed.

For new customers, changes can also use the Category, Type and Item classification, for example Hardware > Laptop > Battery replacement.

The Requester and Status attributes are always present in a change.

The Requester identifies who initiated the change, whether that’s an employee, an agent or admin. It is automatically populated when the change is created, always visible, and not editable by workspace members. It remains required at all stages of the change to maintain accountability.
The Status represents the current progress of the change. It is always visible and required throughout the change lifecycle. It can be manually updated or may be updated by the system as part of workflow actions.

Custom attributes

To capture information that’s specific to your organization or change type, you can add custom attributes to any change template. Custom attributes let you extend the form beyond the common attributes.

Adding a custom attribute to a change template

To add a custom attribute to an existing change template:

Go to Settings > Enterprise automation > Service catalog. Select Organization to apply this across the organization, or select a workspace to apply it to that workspace only.
Select the Change management tab to view all available change templates.
Select the template you want to edit. You will see a list of common attributes as well as custom attributes for the template.
To add a custom attribute, click Add attribute in the Attributes specific to this template section.
Enter the following details for the attribute:
- Response type: Choose the type of input (Short text, Number, Date, People, Dropdown, etc.).
- Display name: Enter a label for the attribute (for example, Change owner or Rollback plan).
- Date and time validation: For Date-time attributes, choose whether the field accepts only past dates, only future dates, or both.
- You can also add a hint or prefill value to guide users when filling out the attribute.
Under Access settings, define when and how the attribute should appear or be edited.

See Access settings for change attributes for more details.

Click Add to save the new attribute to the template.
Once you’re done editing the template, click Update at the top right to publish the template.

To learn how to create a change, see How to create changes.

Access settings for change attributes

Access settings define how each attribute behaves across the change lifecycle — whether it’s visible, editable or required during creation, updates, and closure. These controls help you design structured forms, guide users to enter the right information at the right time, and keep attributes hidden or locked when needed.

You can configure these access settings for both common and custom attributes in change templates. These settings are separate from requester settings and apply wherever change attributes are used by agents in the workspace:

When creating a change and editing attributes
In the Update attributes action in workflows
When attributes appear as placeholders in automations or messages

Available access settings

Setting	Description
Visible in all forms	Displays the attribute on create, and when updating or closing the change. If cleared, the attribute is hidden from users but remains available in workflows, filters, and placeholders.
Editable during creation	Agents can set the value while creating a change. If cleared, the attribute is read-only (if visible) or hidden.
Editable post-creation	Agents can edit the attribute after the change is created, such as during review or implementation. If cleared, the attribute is read-only throughout the change lifecycle unless required on closure.
Required during creation	The attribute must have a value to submit a new change.
Required on closure	The field must have a value before the change can be closed.
Prefill with value (optional)	Assigns a default value when the change is created. Prefilled attributes follow the same visibility and edit rules.

Requester settings for change attributes

Requester settings control how employees who raise changes interact with each attribute. Configure these controls separately from agent access settings so requester forms show only the fields employees need to provide or update.

Requester settings also drive the forms employees see when they select Create > Raise a change in the portal or raise a change through Atom in Slack, Microsoft Teams, or the browser.

Requester setting	Description
Visible to requester	Allows the requester to view the attribute on the change.
Editable by requester during creation	Allows the requester to enter or change the attribute value while creating the change.
Editable by requester post creation	Allows the requester to update the attribute after the change is created.
Required during requester creation	Requires the requester to provide a value before submitting the change.

How these settings work together

These settings are independent, meaning the system does not auto-check or auto-inherit behaviors.

If an attribute is visible but not editable, users can see it but cannot change it.
If an attribute is required on closure, users must complete it before closing the change, even if it was not visible at creation.
Attributes with default values are visible automatically, even when they are not required.

Here are some example attribute configurations to illustrate how different access combinations work:

Example attribute	What it does	Visible	Editable on create	Editable post creation	Required on create	Required on closure
Implementation window	Auto-calculated value that agents can see but never alter.	✅	❌	❌	❌	❌
Risk classification	Internal attribute auto-generated and used in workflows to route the change correctly but hidden from agents to prevent tampering.	❌	❌	❌	✅	❌
CAB decision	Attribute to be filled only at closure, not editable by agents beforehand.	❌	❌	❌	❌	✅
Auto-approval eligibility	Powers workflow logic to determine if a change can skip approvals; never shown to agents.	❌	❌	❌	❌	❌
Testing complete	Filled by agents after testing is complete but not to be altered during creation.	✅	❌	✅	❌	❌
Security review required	Requester must confirm whether a security review is needed when creating the change. The attribute is made visible at creation to meet the requirement, then remains hidden for the rest of the lifecycle.	❌	❌	✅	✅	❌