How to design custom approval workflows in Anaplan for deal desk teams

If your deal desk process lives in spreadsheets and half-baked email chains, you’re not alone. But when deals get complex, approvals fall through the cracks. This guide is for ops folks, admins, or anyone tired of chasing signatures. We’ll walk through how to build a custom approval workflow in Anaplan that’s actually usable—without creating a monster you’ll regret.

Let’s get real about what works, what doesn’t, and what’s just a time sink.

1. Figure Out What You Actually Need (Not What Looks Fancy)

Before you start clicking around in Anaplan, map out what the approval process should really look like. Skip the urge to automate everything. Most teams only need:

  • A way to route deals to the right people
  • Clear status tracking (not just “submitted” or “approved”)
  • Simple audit trail—who did what, and when

Don’t overengineer: If your process fits on a napkin, keep it that way. Extra fields and stages only create confusion (and bugs).

Pro tip: Talk to the people actually doing the approvals. Their pain points are your requirements.

2. Sketch Out Your Workflow Steps

Lay out the specific stages a deal should go through. For a typical deal desk approval, that might be:

  1. Submitted (by sales rep)
  2. Manager Review
  3. Finance Review
  4. Legal Review (if needed)
  5. Final Approval
  6. Completed / Rejected

Don’t get cute: If you can’t explain each step in a sentence, it probably doesn’t belong.

Branching logic: Do all deals need legal? Should finance come before or after manager? Write down which steps are conditional.

3. Model Your Workflow in Anaplan

Here’s where most people overcomplicate things. Anaplan isn’t a dedicated workflow tool, but it’s flexible. You’ll mostly be using:

  • Lists: For deals, users, approval steps
  • Modules: For tracking deal records and their approval status
  • Line items: For fields like “Current Status,” “Assigned To,” “Last Action Date”

Minimum viable structure:

  • Deal List: Each deal is a list item, probably tied to an opportunity ID.
  • User List: Everyone who might touch the process.
  • Approval Steps List: Submitted, Manager Review, etc.

Module example:
A “Deal Approvals” module with the Deal list as the dimension. Key line items:

  • Current Status (List formatted: Approval Steps)
  • Assigned Approver (List formatted: User)
  • Last Action Date (Date)
  • Last Action By (User)
  • Comments (Text)

Pro tip: Don’t build a separate module for every step. Use lists and statuses to keep things tidy and future-proof.

4. Set Up Logic for Routing and Tracking

This is where you tell Anaplan when to move a deal to the next step, and who should be notified.

Key questions:

  • How does a deal move forward? Manual button, formula, or both?
  • Who “owns” the deal at each step?
  • How do you prevent someone from skipping steps?

Practical setup:

  • Use Boolean line items like Ready for Manager Review? and Ready for Finance Review? tied to status changes.
  • Use formulas to assign the next approver based on the current step and deal attributes (e.g., deal size).
  • Optionally, set up action buttons (via Anaplan’s UX) for reviewers to approve/reject.
  • Lock down editing rights so only the right person can act at each step.

What doesn’t work well:

  • Trying to automate every possible exception. You’ll end up with a spiderweb of logic that’s impossible to troubleshoot.
  • Overreliance on automation for notifications—Anaplan isn’t a replacement for Slack or email for alerts, though you can integrate if it’s worth the effort.

5. Build the User Experience (Keep It Simple)

If the UI is confusing, nobody will use it. The best Anaplan workflows have:

  • Landing page: Shows each user what deals need their attention.
  • Single-view deal page: All relevant details and action buttons are on one screen.
  • Status dashboard: For ops or admins to see bottlenecks and stuck deals.

Avoid:

  • Making users click through five screens to approve a deal.
  • Hiding critical info behind multiple layers.

Pro tip: Ask a couple of users to break your workflow. If they can get a deal stuck or skip a step, you’ve got work to do.

6. Handle Exceptions Without Making a Mess

No workflow survives first contact with reality. People will need to skip steps, deals will need to be escalated, and someone will always forget to fill in a field.

Simple ways to handle exceptions:

  • Add a manual “Override” or “Escalate” action, with a required comment.
  • Track overrides in an audit trail (just another text/date/user line item).
  • Keep exception paths visible, not hidden. You’ll need to report on them.

What to avoid:
Hardcoding dozens of “if this, then that” exceptions. It’ll only make maintenance a nightmare. Keep exception handling obvious and auditable.

7. Test, Roll Out, and Actually Listen

Before you ship, run through real deals with the team. Don’t just click through yourself—watch others use it.

  • Document pain points as you go.
  • Don’t ignore feedback just because it means rework.
  • Plan for a few iterations. The first version will probably miss something.

Pro tip: Don’t let perfect be the enemy of good. A working, clearly-documented process beats a “smart” but broken one.

What Works, What Doesn’t, and What to Ignore

What works:

  • Keeping status and ownership crystal clear
  • Using lists and modules to keep the model maintainable
  • Making sure every action leaves a trace (auditability)

What doesn’t:

  • Overly granular steps (“Legal Review Part 1,” “Legal Review Part 2”)—nobody needs that level of detail
  • Relying on Anaplan for complex notification workflows (use another tool if you need bells and whistles)
  • Building for edge cases instead of everyday use

Ignore:

  • Fancy dashboard charts about approval times (unless you’ll actually act on them)
  • Automating every possible path—cover the basics first

Keep It Simple, Iterate, and Don’t Overthink

Custom approval workflows in Anaplan don’t have to be a headache. Start with the minimum you need, focus on clarity, and expect to tweak things as you go. The best workflows are the ones people actually use—so keep talking to your team, stay skeptical of gold-plated features, and don’t be afraid to rip out what isn’t working.

You’ll save yourself a ton of trouble if you build for the real world, not the whiteboard. Now get after it.