Change Requests

Most teams manage process changes through a mix of emails, paper forms, and manual approvals — leaving the request, the change, and the approval disconnected from each other and from the system itself. In Threaded, a Change Request (CR) is a key part of Version Control that ties all of that together: it’s how a process change moves from Development to Production, capturing the who, what, and why of every change directly inside the system.

#What a Change Request Contains

Every Change Request includes:

• Name: A clear label for the change being made
• Description and Reason: Context for what is changing and why
• Creator: The editor who opened the CR
• Scope: The specific parts of the process that are being modified

A CR can cover a single instruction or span multiple instructions across the value stream. Either way, it represents one cohesive improvement being released together.

#Who Can Open a Change Request

Change Requests can be opened by any Editor in an organization. Editors are the process owners and approvers responsible for maintaining and improving the instruction set. These are typically process or manufacturing engineers, quality team members, and managers of those teams.

Threaded users without Edit permissions, such as Operators, are unable to open Change Requests. If someone on the floor has feedback about a process, that flows through a separate actions workflow, where an engineer or other team member with Editor access can review and act on it.

#The Workflow: Draft → Change Request → Review → Publish

#1. Draft changes in Development

Editors can make changes to a draft in the Development environment freely without a Change Request. Add or change procedures, update cycle times, revise tooling, reorganize the flow. All of this can happen in Development without affecting what’s live in Production, and the drafted changes will persist until modified or published.

#2. Open a Change Request

When the change is ready to go to Production, an Editor opens a Change Request by clicking the “New Change Request” button under the Version Control tab. The CR captures the name, description, and scope of the change, and initiates the review and approval workflow.

#3. Review

A reviewer can be any other Editor in the organization. When they open the CR that is ready for review, they will see tabs for Conversation, Changes and Instructions. Only the subset of the process selected in the CR is surfaced for review, and unchanged instructions are not included.

The “Conversation” tab gives the user a place to provide and respond to feedback before approval, and run and review Process CI checks.

When they navigate to the “Changes” tab within a Change Request, they will see a clear diff showing exactly what has changed - instructions, wording, structure, parts, tools, and more.

The “Instructions” tab will show a clear visual comparison of work instructions before and after the proposed changes.

Additionally, AI-powered CI (Continuous Improvement/Continuous Integration) checks in the conversation tab automatically identify issues with completeness or quality, catching issues with images or language used in the instruction set that may make it difficult for operators to follow the instructions. All before a CR is approved and without the need of a full-time technical writer to review. This function can be kicked off at any time, by any editor or approver to support.

Reviews and CI checks can be set as required for release in the Configuration pane for Version control, or can be left as optional according to the needs of the organization. Reviews are the primary collaboration function in Threaded where a team can review, test, and edit changes together before releasing them to Production.

#4. Publish to Production

While under review, a CR will be marked as “pending” under Change Control. Once approved, the changes are published as a new version of the instruction set in Production. The Change Request is then automatically marked as released and becomes part of the version record — timestamped, attributed, and permanently linked to that release.

#The Audit Trail, Built In

The collaborative CR review process drives alignment, clarity, and education for the team developing the process. It ensures that changes to your instruction set are controlled, visible, and understood by the team before they reach Production. Compliance frameworks like ISO 9001 also require this type of review and approval, and in Threaded that requirement is satisfied as a natural outcome of the CR workflow — not as a separate documentation exercise after the fact. Every published version has an associated CR that records what changed, who requested it, and who approved it, building a complete improvement record and history along the way.