Plans and staged changes
Konnie can turn a configuration request into a plan and staged candidate changes. This gives you a place to inspect the proposed result, resolve questions, and decide how work should proceed. Availability depends on the target entity, current permissions, and enabled capabilities.
Work directly with saved drafts
Apps, Materials, bills of materials and Routings use their actual saved working drafts. Ask Konnie to create or edit the definition; no implementation plan or staged-change acceptance is required. A compact card in the conversation opens the current saved draft in the canvas. From there, open the same object in Operations Studio and continue with Konnie in the right-hand drawer.
Review the resulting definition and continue editing through Konnie or Studio. Saving preserves the working version; publication is a separate explicit action using your current permissions and the reviewed revision. Another author's changes can require a refresh and reconciliation before saving or publishing. Publish a new material before its BoM or Routing; component materials must also be published before the BoM. Releasing a new BoM or Routing does not replace the captured definitions of existing production orders.
The staged-change instructions below apply to other supported entity types. Historical staged records for direct-draft types remain available for reference; continue work on their actual saved objects.
Complete work with Full autonomy
When Full autonomy is on for this conversation, ask for the result you need. Konnie can persist an execution-approved plan, prepare related changes, finish canonical application and publication, and verify the resulting records without asking separately to approve the plan, accept changes or publish. Staging still prepares drafts; Konnie continues the tool workflow to publication instead of treating drafts as completion.
Dependencies are staged and published coherently. Large artifact batches can run in the background; Konnie inspects their progress and uses the same saved plan and revisions. Missing essential choices, current access restrictions, stale versions and required native business approvals can still need attention. Explicit requests for a plan or drafts stop at that requested boundary. With Full autonomy off, use the review workflow below. See the composer control for remembered defaults and branch behavior.
Prepare a plan for review
- Describe the outcome, target site/environment, and constraints in a conversation.
- Provide sources and identify records that should be updated rather than duplicated.
- Ask Konnie to prepare an implementation plan.
- Open the plan canvas and review its description, summary, open questions, steps, and dependencies.
- Add comments or answer open questions and request a revision before approving incomplete work.
Example: “Prepare a request workflow with a Table for material, quantity and note, and an App that saves one request directly. Add an Automation only for required follow-up processing. Show the dependencies and identify decisions still needed.”
A plan is a description. Approving it does not by itself prove the configuration was saved, published, activated, or tested.
Konnie completes changes automatically when your current permissions and configured action policy permit execution. When review is required, supported internal Konnie batches and native tool changes use the staged-change review beside the conversation. External-agent CLI operations use their delegated direct-draft/command workflow rather than this acceptance queue. Clicking a change link opens this review while keeping the conversation available.
Review staged changes
Open the changes/review section of the canvas. For each change, inspect the entity, create/update/delete operation, before-and-after values, dependencies, and source. For updates, verify the existing target. Mark it Accepted, Rejected, or Needs revision, and add a note when the reason will help Konnie correct the proposal.
| Status | Meaning |
|---|---|
| Pending | Candidate awaiting review. |
| Accepted | Reviewed positively; application is still a separate step. |
| Rejected | This candidate should not be applied. |
| Needs revision | Correction is required before application. |
| Applied | Saved through the target's publication/change workflow. |
Use Accept and apply all for eligible pending/accepted changes in the current batch, or apply individual reviewed changes. A separate bulk acceptance step is optional. Check the resulting count, failures, and record links. Some domains require further publication, activation, access setup, or runtime testing. An applied candidate is not evidence that an operator completed the workflow.
Review larger file-derived batches
A workbook or other analyzed source can produce a grouped change set. The group shows totals and status counts, and rows can be searched, filtered, and opened for details. Source information, such as a filename, worksheet, or row reference, helps you compare proposals with the original file.
Ready, Blocked, Unchanged, Staging, Staged, and Failed describe preparation/staging, while the row's review status describes acceptance/application. A ready row is not live data. Unchanged rows need no new change. Blocked or failed rows need attention before they can proceed.
Review a representative sample and all flagged rows; for consequential batches, inspect every proposed effect according to your organization's review procedure. Group actions apply to the current staged candidates in the reviewed revision. Accept and apply all combines the decision and application; it does not make unstaged, rejected or blocked rows eligible. If the group changed while you reviewed it, refresh and review the current revision.
Let Konnie finish a supported plan
Where the plan panel offers Let Konnie finish, you can delegate the exact reviewed plan revision. The current bounded workflow supports create/update steps for eligible Tables, Automations and work centers, with at most 30 steps and no unresolved questions.
Delegation can publish eligible dependencies and activate supported Automations. Standalone Form creation, capture and submission bindings are retired; historical plan entries do not restore them. It excludes deletes, access-policy/grant changes, external integration writes, and arbitrary executable App/code effects. Broader work needs its own review path. Current permissions and session validity continue to apply.
After starting, the assignment remains linked to the original conversation and can continue while the browser is closed. Return to the plan to inspect its state, questions, errors, and per-artifact receipts. Queued and Running mean work is ongoing. Waiting for input/review needs your decision. Completed describes verified configuration readiness, not a business submission or customer acceptance.
Use Pause, Continue, or Stop as offered. These prevent subsequent work according to the assignment state; an action already underway may finish and completed changes remain saved. Delegation has a bounded execution budget and a 24-hour authorization horizon. An expired session, changed plan, or exhausted budget can require a new decision or fresh login before continuing.
Verify the outcome
Open the resulting records and published versions. Check bindings and intended audience, then run an explicitly authorized test of the actual workflow: load the App as the intended operator, submit harmless App input, verify one destination row and any separately configured Automation outcome, and test denied access. Configuration readback alone cannot prove these runtime outcomes.
If an action reports an uncertain write/publication result, inspect live records and receipts before resuming. Do not duplicate an entity because a response was lost. If dependencies conflict with an active Automation or another editor changed a record, resolve the compatibility issue and obtain a current preview.
See governance, Operations Studio publishing, and Apps and workflows.