Workday Configuration Workbook Readiness Checklist

A workbook is useful as an execution plan only when another person can understand what should change, where it should change, and how the result will be checked. Use this checklist before a manual build or an automation evaluation.

1. Identify the target and owner

State the configuration area, intended sandbox or implementation tenant, design owner, and reviewer. Confirm the account has the access needed for the approved tasks. Keep credentials outside the workbook.

2. Give each row a stable identity

Use a unique row identifier and a precise task or object description. Avoid relying on display order alone. Stable IDs help the team connect a design decision to a build result, issue, and verification record.

3. Specify the intended values

Include the required fields and clarify which blanks are intentional. Resolve phrases such as “same as existing” into an explicit reference and comparison rule. Do not ask the executor to infer a business decision from incomplete notes.

4. Resolve dependencies

Identify prerequisites such as existing reference data, approved business-process decisions, or integration definitions. Put the work in an order the reviewer understands. An approved row may still be blocked by an unready dependency.

5. Record approval separately

Identify who approved each intended change and when. Keep proposed, approved, built, and verified work distinguishable. Decide which actions need an additional gate immediately before execution, including sensitive security changes and data loads.

6. Prepare actual data for loads

A description of a load is not the source data. Identify the authorized source records, mapping, expected count, and compatible tenant-specific template. Review the prepared file before approving the load. Recheck approval if the file changes.

7. Define evidence before the build

Specify the saved fields to read back and compare. For loads, define reconciliation requirements and how the team will inspect the completed event. Record what cannot be verified rather than treating a missing check as a successful result.

8. Decide how to handle exceptions

Document what happens when an object already exists, a value differs, a required field is missing, or an action’s outcome is uncertain. Name an owner for open issues. Stopping a run does not undo changes already submitted.

9. Make handoff part of the scope

Keep the approved design, change log, result status, verification evidence, and issue list together. A reviewer should be able to trace a row from intended value to observed result without reconstructing the whole session.

Try a small sample first

Choose a few representative rows and review them with someone who did not write the workbook. If they cannot tell what should happen and how to verify it, fix the design before scaling the build.

For automation, review the console’s current scope and limitations. For hands-on help preparing configuration and validation work, our partner Evolved Consulting provides Workday Financials consulting.

← All insights