Change Plans
Create, review, approve, and execute Splunk configuration changes across your fleet
Change Plans
Change plans bundle configuration changes for your Splunk fleet. Each plan goes through a lifecycle of creation, review, approval, and execution — giving you governance and traceability for every config change.
Navigation
- Parent: Automation Platform
- Previous: Insights Nodes
- Next: Executions
- Related: Splunk Execution Credentials | Deslicer Automation Copilot | Chatting with Agents
Plans List
Navigate to Automation Platform → Plans to see all change plans. You can filter by status and search by plan name, ID, or commit SHA.
Plan Statuses
| Status | Meaning |
|---|---|
| Draft | Plan is being prepared — not yet submitted for approval |
| Pending | Submitted for approval — waiting for a reviewer |
| Approved | Approved and ready to execute |
| Executing | Currently being rolled out to target nodes |
| Completed | Successfully applied to all target nodes |
| Failed | Execution encountered errors on one or more nodes |
| Rejected | Reviewer declined the plan |
| Cancelled | Plan was cancelled before execution |
Plan Properties
Each plan displays:
- Plan name and description
- Source type — where the plan originated (manual, agent-generated, compliance remediation, or Git-linked)
- Repository and commit — for Git-sourced plans, the linked repo URL and commit SHA
- Target group — the host group this plan targets, with group name and identifier
- Target hosts — the individual member hosts in the target group, with hostnames and links to their node detail pages
- Trusted source indicator — whether the plan comes from a verified source
- Destructive change warning — flagged when the plan removes or overwrites existing configs
- Approval trail — who approved or rejected the plan, and when
Target Group and Host Visibility
The plan detail sidebar shows the Target Group assigned to the plan and lists the Target Hosts — the individual enrolled nodes that will receive the configuration changes when the plan executes. Each host entry links to its node detail page for quick inspection.
If a target group has no members, a warning appears: "This group has 0 members — execution will produce 0 jobs." This helps you catch empty groups before executing a plan that would silently do nothing. If the target group has been deleted since the plan was created, a "Group not found" notice appears.
Plans without a target group cannot be executed. You must assign a target group before approval.
Plan Status Accuracy
The Plans list derives the effective status from the latest execution when the stored plan status lags behind reality. For example, a plan that still shows Failed in the database but whose latest execution ultimately succeeded displays as Completed. The Latest execution column links to that run and shows inline progress — waiting for worker, jobs running, or succeeded/failed job counts.
Retry from the Plans List
When a plan's latest execution failed, was canceled, or ended partial, a Retry action appears on the plan row. Retry re-queues only failed or canceled jobs; hosts that already succeeded are skipped. You cannot retry while an execution is still queued or running.
Creating a Plan
- Click New Plan on the Plans page.
- Enter a plan name and description.
- Add configuration changes — specify which files and stanzas to create, modify, or remove.
- Submit for approval or save as a draft.
Plans can also be created programmatically by the App Deployment Agent or via the Observer API.
Inline Plan Drafting
When an AI agent identifies a remediation — for example, from a compliance audit or a security baseline violation — it can author change items directly in the chat and submit them as a plan draft. The agent follows a two-step flow:
- Create the plan — the agent calls the Observer API to create a new draft plan with a name, description, and target host group.
- Submit the draft — the agent attaches inline change items to the plan. Each item specifies the app, config file, stanza, key, desired value, and change type (addition, modification, or deletion).
Before the draft is persisted, you see a confirmation card in the chat that lists every change item in a grouped layout organized by host, app, file, and stanza. You must review and approve the card before any changes are staged. See DAP Confirmation Cards for details.
Approval Workflow
Change plans require explicit approval before execution. This human-in-the-loop design prevents unreviewed changes from reaching production Splunk environments.
- A plan is submitted with status Pending.
- A reviewer inspects the proposed changes.
- The reviewer clicks Approve or Reject.
- Approved plans can then be executed.
In-Chat Approval
When you work with a DAP agent, plan lifecycle actions — approving, rejecting, executing, compiling, retrying, and deleting — are gated by interactive confirmation cards directly in the chat. The agent proposes the action, and you approve or cancel it from the card without leaving the conversation. See DAP Confirmation Cards for the full list of gated actions and how the cards work.
Approval Prerequisites
Before a plan can be approved, every targeted host must satisfy Splunk session prerequisites:
| Prerequisite | What to Do |
|---|---|
| Splunk management credentials | Register credentials on Splunk Credentials that cover each host (tenant default, host group, or per-host scope). |
| Worker enrollment | Ensure worker hosts enrolled with a bootstrap package that submitted their age public key. Re-enroll hosts that predate phase-auth support. |
When prerequisites are missing, the Approve Plan dialog shows an amber guidance banner listing affected hosts and links to Open Splunk Credentials or Open Enrollment as appropriate. The same guidance appears on Approve Plan confirmation cards in agent chat when approval fails for the same reason.
Human approval from a signed-in dashboard session is required for plan approval — API-key-only sessions cannot satisfy the human-attestation gate.
Executing a Plan
Once approved, click Execute to begin rollout. The plan transitions through Executing → Completed (or Failed if errors occur). Track live progress on the Executions page.
Splunk Credential Readiness
Before rollout starts, Deslicer verifies that Splunk execution credentials cover every host the plan will touch. When you open the Execute dialog:
- A Checking Splunk execution credentials indicator appears while coverage is evaluated.
- If credentials are ready, you choose a rollout strategy and confirm.
- If credentials are missing, an amber warning explains what is needed — for example, a tenant default, a host-group credential for the plan's target group, or per-host credentials for individually targeted hosts. Click Open Splunk Credentials to configure them.
Coverage follows the most-specific-wins rule: a host-scoped credential satisfies that host; otherwise a matching host-group credential or tenant default can satisfy the plan. Compliance and remediation plans that attach changes to individual hosts are checked against those specific hosts, not only the target group membership.
Execution is blocked until coverage is complete. Configure credentials on Automation Platform → Platform → Splunk Credentials before your first production rollout.
Deleting a Plan
You can delete plans in Draft, Approved, or Rejected status. Plans that are currently executing or have completed cannot be deleted. When you delete a plan through an agent, a confirmation card appears requiring your approval before the deletion proceeds.
