Author a config runbook

A config runbook is a batch of device configuration changes you plan and apply together, over the Ricoh Web Image Monitor. Instead of logging into each copier’s panel one at a time, you gather the changes once, see exactly what would change on every device, and commit them in one guarded step. This is an admin-only task, and every write that goes out is recorded in the audit log.

How it works

You author a runbook as a list of steps, each targeting a device and setting one value. Planning the runbook reads every target device and caches a diff (what is set now, what would change) without writing anything. Applying is the guarded step: it requires an admin, a configured device connection, and a typed confirmation that matches the runbook’s name. The plan and apply work runs off-request on a dedicated queue, and each applied step lands as a device-write entry in the audit log.

flowchart LR
  D[Draft] -->|add steps| S[Steps]
  S -->|plan| P[Planned + cached diffs]
  P -->|type the name to confirm| A[Apply]
  A --> W[Device write + audit row]

Steps

1. Create a runbook. It starts as a draft. Give it a clear name; you will type that name back to confirm the apply, so make it specific.
2. Add steps. Each step targets a device and sets one configuration value. Build up the whole batch before you plan it.
3. Plan it (dry-run). Planning reads each device and caches the diff for every step. Nothing is written yet. Review the diffs: confirm that the “now” column matches what you expect and the “would change” column is only what you intend.
4. Apply. Applying is the molly-guard. You must be an admin, the device connection must be configured, and you type the runbook’s name to confirm. The worker then applies each step and writes a device-write audit row as it goes.
5. Schedule (optional). A planned runbook can be scheduled to apply later instead of immediately.

Why the dry-run matters

A config change pushed to the wrong device, or a value set wider than intended, is the kind of mistake that is easy to make across a fleet and hard to notice after the fact. Planning first turns the whole batch into a reviewable diff before a single write leaves the broker, so you catch a wrong target or a surprising “now” value while it is still safe to fix.

What is recorded

Every applied step is a device-write entry in the audit log: what was changed, on which device, by whom, and when. Device writes are logged the same way PHI reads are, so the configuration history of the fleet is on the record alongside everything else.