A well-designed planning cycle makes it clear who updates the plan, what reviewers should check, and how decisions move forward. Pigment workflow design should make that process visible without turning each forecast into a maze of handoffs. Start with a specific planning decision, define ownership and review criteria, then test the cycle with the people who will use it.

Get in touch to discuss your planning workflow

What should a reviewable planning workflow accomplish?

A workflow is more than a calendar of due dates. It connects planning tasks to decision-making: the right people provide inputs, reviewers see what changed, and Finance can resolve exceptions before publishing a forecast or budget. In an EPM application, workflow design also needs to fit the model structure, data sources, access rules, and reporting outputs.

A useful workflow makes five things easy to answer:

• What is being planned? Name the deliverable, such as a quarterly revenue forecast, annual operating plan, or headcount outlook.

• Who owns each input? Assign responsibility at the level where the information is known and can be maintained.

• What is the review standard? Set the checks that make an input ready for review and explain how exceptions are handled.

• What changes when an item is submitted? Make the handoff and expected reviewer action clear.

• What decision does the process support? Identify the point at which leaders use the plan and what happens next.

If participants cannot tell whether they are entering data, checking assumptions, or approving a decision, the workflow is not yet clear. Write down the intended sequence before configuring application steps. This is especially important when a process crosses Finance, Sales, Operations, or HR; each group may use the same terms differently.

Define success in operational terms before building. For example, a forecast cycle may be ready when all territory owners have submitted capacity and bookings assumptions, Finance has reconciled the consolidated view, and material changes have a named decision-maker. That is more useful than a vague goal such as “make forecasting faster.” It gives the design team concrete conditions to test and helps users understand what completion means.

How should Finance map the planning cycle?

Begin with the current planning process, but do not assume every existing handoff should be reproduced. Map the cycle from launch to decision. Include the event that starts each task, the responsible role, the required input, the review, the output, and the next handoff.

For example, a revenue forecast cycle might begin when Finance opens a forecast period. Sales leaders update quota attainment assumptions, capacity, territory coverage, and expected bookings. Finance checks the submission against actuals, the prior forecast, and agreed operating assumptions. Finance and Sales discuss material variances, update the forecast where appropriate, and present a consolidated view to leadership. The process ends when leaders use the forecast to make decisions, not merely when a form is submitted.

Document the real process in a simple sequence. Note where the work is parallel and where one task depends on another. Identify who resolves a disagreement, what counts as a late or incomplete input, and whether a review can return an item for correction. This creates a practical design specification and exposes needless handoffs before they become application requirements.

Keep the map focused on decision-critical actions. An approval step that does not change a decision, add a control, or clarify accountability may add delay without improving the plan. Conversely, a material assumption should not pass through the cycle without an owner and a review standard.

A short mapping workshop can make this concrete. Put the cycle on a shared page with columns for step, trigger, owner, input, reviewer, expected outcome, and dependency. Ask each participant to describe what they do today, including the spreadsheets, messages, and informal checks that sit outside the official process. Then mark every handoff that changes the plan or verifies an important assumption. If a step only forwards information, ask whether the application can make that information available to the next owner without a separate approval.

Finally, separate the recurring workflow from one-time setup work. A cycle may need a calendar and assumptions set at launch, but that does not mean every cycle should repeat a lengthy design approval. Keep the recurring path lean, and identify which decisions belong to governance or model maintenance rather than to each forecast submission.

Amvent’s article on EPM implementation team roles can help clarify who should make design decisions and who should own delivery tasks. For a broader view of implementation stages, see the Pigment implementation methodology.

How should owners, reviewers, and decision-makers be assigned?

Assign roles based on the work people can perform, not just their place on an organization chart. Input owners should understand the underlying business activity and have access to the data needed to explain their assumptions. Reviewers should have enough context to challenge the submission. A decision-maker should be named for issues that cannot be resolved within the working team.

A responsibility table helps the team agree on expectations before the cycle is built:

Make role names understandable to users. If the same person enters and reviews information in a small team, document that exception rather than designing a process that assumes separate staff. If the review requires independent control, then separate responsibilities where practical and align the system’s access design with the organization’s policies.

Access and workflow ownership are connected but not identical. A person may need to view a plan without editing it, or edit one planning area but not another. Define what each role needs to see and change before configuration. Amvent’s guides to access management in Pigment and Pigment access management implementation provide related context.

Use a responsibility matrix to resolve overlaps. If a regional leader owns an input and a functional leader reviews it, specify who acts when their views differ. A practical rule might be that the owner updates the assumption, the reviewer documents the concern, and a named Finance or business leader decides if the disagreement affects the consolidated plan. The system should make that route visible rather than leaving users to infer it from job titles.

How should inputs and review criteria be defined?

Reviewable inputs need more than a number. For each important input, determine its source, level of detail, time period, owner, and explanation requirement. A bookings assumption, for example, may need to be understood by territory, product, or sales segment, depending on how the organization manages performance. The model should reflect the decisions the plan supports, not every possible detail.

Define checks that help reviewers focus attention. These may include whether a required input is present, whether a value falls outside an agreed range, whether a material change has an explanation, or whether totals reconcile to a trusted source. The exact checks depend on the planning process and the data available. Do not impose arbitrary thresholds that users cannot explain.

Differentiate a validation check from a business judgment. A missing value can be flagged automatically if the input is required. Whether a hiring plan is realistic is a management judgment and needs a reviewer with the right context. Clear workflow design shows which items are objective checks and which require discussion.

For each check, document the expected response. A warning that says a forecast moved substantially is not useful if nobody knows whether to add commentary, resubmit, or escalate. For example, a required-input check can block submission until the owner completes the field; a variance flag can allow submission but route the change for review; a reconciliation issue may send the consolidated plan back to Finance for investigation. Set the response according to the consequence, not simply because a rule is easy to configure.

Keep the model’s level of detail workable. More detail can make submissions harder to complete and reviews harder to interpret. For help thinking through the trade-off between granularity and usability, see how to choose the right model dimensions and sparsity management in EPM systems.

How can reviewers see what changed and why?

A reviewer needs a useful comparison, not just a new set of numbers. Decide which reference points matter for each cycle. Common comparisons include actual results, the previous forecast, the approved budget, and an earlier scenario. Use only the comparisons that help explain decisions. Too many reference columns can obscure the signal.

Ask input owners to explain material movements in business language. For a revenue plan, the explanation might distinguish a change in quota capacity from a change in expected attainment. For workforce, it might separate approved positions from timing shifts. The purpose is not to create commentary for every cell; it is to make significant assumptions and changes traceable.

Set a consistent review rhythm. A reviewer might check completeness first, challenge assumptions second, and assess consolidated impact after updates. Where possible, group exceptions by owner or planning area so that discussions result in specific actions. Record decisions and the rationale at the level needed for the next forecast cycle.

One useful review sequence is to start with a summary of the largest movements, then inspect the drivers behind each movement, and finally consider the total plan. Suppose bookings are below the prior forecast in two territories. A reviewer can first confirm whether actuals changed, then check whether capacity, quota, or expected attainment explains the gap, and then assess whether the consolidated revenue outlook needs a management response. This sequence links commentary to the decision instead of generating notes that are disconnected from the model.

Agree on how the team will distinguish a changed assumption from a changed result. A number may move because a source system refreshed, an owner revised an assumption, or Finance corrected an error. These are not interchangeable explanations. Recording the reason and the responsible owner makes it easier to compare cycles and prevents a reviewer from treating every movement as a new business signal.

External research on workflow design in a different setting describes the value of clear guidelines and visible progress for coordinated work. It is a limited analogy, not evidence about finance applications; the planning team should test its own handoffs and review criteria. Read the workflow-design research.

How should the workflow handle exceptions and late changes?

Even a well-planned cycle will encounter missing inputs, conflicting assumptions, and changes after submission. Define an exception path before the first live cycle. Establish who can send an item back, who owns the correction, how the issue is escalated, and what happens if a deadline is at risk.

Distinguish exceptions by consequence. A missing required input may prevent consolidation. A small variance may need an explanation but not a leadership decision. A major change to an operating assumption may require a discussion between Finance and the relevant business leader. Giving each kind of issue a proportionate response avoids treating every deviation as an emergency.

Late changes need particular care. Decide whether the plan is still open for edits, who can reopen a submitted item, and how downstream reviewers will know a number has changed. Preserve a usable record of the decision and its effect on the consolidated view. Do not rely on informal messages as the only record of a material change.

Consider how the process will work when someone is unavailable. A substitute or escalation path can prevent one missed handoff from stopping the whole cycle. Keep any delegation rules aligned with the organization’s governance and access requirements.

Make exception handling specific enough to act on. For a returned submission, tell the owner what needs correction, who requested it, and whether the original deadline still applies. For a deadline risk, identify the person who can approve a revised sequence or accept an interim assumption. For a late change after consolidation, show which totals and outputs may be affected and require the relevant reviewer to confirm the revised view. A clear path avoids parallel versions circulating through email or chat.

It also helps to define what does not count as an exception. Minor rounding differences, for example, may be acceptable when they do not affect the decision. If users are expected to escalate every small discrepancy, reviewers will spend time sorting noise from material issues. Set boundaries that are understandable to the people entering and reviewing the plan, and revisit them after the first cycle if the rules produce too many false alarms.

How can a finance team test the design before rollout?

Test with realistic cases, not just a clean demonstration. Use one complete planning cycle or a representative slice of it. Include routine inputs, an incomplete submission, a material variance, a returned item, and a late change. Ask users to perform the actual tasks and explain what they believe happens next.

During testing, track more than whether the model calculates correctly. Check whether people can identify their next action, whether reviewers can find the required context, and whether unresolved issues reach the right decision-maker. Confirm that outputs reconcile to the agreed source data and that access matches role expectations.

Capture feedback in three categories: model or data issue, workflow or handoff issue, and training or communication issue. This distinction helps the team solve the cause rather than adding another process step to compensate for a confusing design. After changes, test the affected part again with the people who use it.

A simple test script can make user testing more consistent. Ask an input owner to enter a normal update, explain a significant movement, and submit it. Ask the reviewer to locate the change, return the item with a clear reason, and then review the corrected version. Finally, ask Finance to consolidate the inputs and explain how it would escalate an unresolved assumption. Observe where people hesitate or take an unintended route; those moments often reveal a missing instruction or unclear responsibility.

Before rollout, confirm the cycle calendar, role assignments, required inputs, review conditions, and support route in one place. Make sure a new participant can tell when the cycle opens, what is expected of them, and where to ask for help. Retest the full route after any change to permissions or handoffs, because a small access adjustment can affect who can complete or review a task.

Begin with a focused planning area when the organization is new to a connected process, then expand when roles, assumptions, and review practices are working. Amvent’s perspective on a gradual path to connected planning explains why an intentional rollout can be easier to sustain than trying to connect every team at once. Teams preparing their first cycle may also find what to expect from a Pigment implementation kickoff useful.

What mistakes make planning workflows hard to review?

• Copying every old handoff. Legacy steps may reflect spreadsheet limitations or unclear ownership. Retain a step only when it supports a control, a decision, or an essential review.

• Making every task an approval. Too many sign-offs obscure the meaningful decisions and can slow the cycle. Match the review to the risk and impact.

• Leaving ownership vague. A group mailbox or department name may not identify who must act. Name a role or accountable owner and define an escalation route.

• Designing around the model rather than the decision. A technically neat model can still fail if users cannot connect inputs to the choices they need to make.

• Capturing commentary without a purpose. Require explanations where they help interpret material movements, not for every unchanged value.

• Testing only the happy path. Missing data and late changes are normal enough to merit deliberate testing.

• Expanding too quickly. Add planning areas when the foundation works and teams understand their responsibilities, not simply because the platform can hold more data.

Another common problem is treating submission as proof of review. A completed task only tells the team that someone finished an action; it does not show whether the input is plausible, reconciled, or ready to inform a decision. Define what evidence reviewers should see and what they need to do with it. That may be a reconciled total, an explanation for a material variance, or a decision recorded for an open assumption.

A strong cycle is disciplined but not rigid. It gives Finance enough control to produce a reliable view while leaving room for business owners to explain what is changing and why. For help connecting requirements to a workable implementation plan, explore EPM requirements gathering or Pigment implementation consulting.

Get in touch to review your planning cycle

Frequently Asked Questions

What is Pigment workflow design?

Pigment workflow design is the process of defining how planning work moves through owners, reviewers, and decision-makers in an EPM implementation using Pigment. It includes the tasks, inputs, validation, handoffs, review criteria, and exception paths needed to produce a usable plan.

Should every planning input require approval?

No. Require a formal review where it supports a meaningful control or decision. Routine inputs may need validation and a manager review, while material assumptions or unresolved exceptions may need explicit leadership attention.

How detailed should workflow steps be?

Detailed enough that a user knows what to do, what complete means, and where to go when something is wrong. Avoid breaking work into small steps that do not improve control, accountability, or visibility.

When should a finance team expand a planning workflow?

Expand after the initial process has clear owners, reliable inputs, useful reviews, and a tested exception path. Then add adjacent planning areas in a way that preserves shared assumptions and makes cross-functional responsibilities explicit.

Make the planning cycle reviewable before it goes live

Start with a specific decision and map the work required to support it. When ownership, input standards, review criteria, and exceptions are clear, a planning workflow can help Finance and operating teams spend less time chasing submissions and more time evaluating the plan.

Get in touch to discuss your Pigment workflow

Get in touch to plan a reviewable cycle

Get in touch with Amvent Consulting to discuss a reviewable planning cycle for your finance team.