Manage attributes that capture key information across every change request.
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 cahnge, 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)
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
|
|
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.
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:
Navigate to Settings > [Your workspace] > Catalogs.
Select the Change 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 on 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.
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 Universal Agent.
|
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.
|
❌
|
❌
|
✅
|
✅
|
❌
The title of the change. Required for all change requests.
