How EspoCRM approval processes with BPM user tasks replace email chains
Approval processes in EspoCRM run as BPMN 2.0 processes with user tasks, so a discount, quote or contract is routed to the right approver inside the record instead of through a chain of forwarded emails. The Advanced Pack provides the Business Process Management engine. A process starts from a record event, creates a user task assigned to an approver, and waits for that person to choose an approve or review action. Gateways then read the decision and send the record down the next path, such as a deal desk review, a signature step or a rejection notice. Every step is written to the process log, which is what auditors and sales leadership usually ask to see when a discount was granted. The Advanced Pack is included in all EspoCRM Cloud plans, according to the EspoCRM pricing page, so confirm with the vendor whether your chosen plan or self-hosted license includes it before you design around it.
Use a simple workflow when one condition sends one notification or one field update, such as flagging a quote over a set amount. Use a BPM user task when a person must make a decision, the decision can return for rework, or more than one approver may be involved in sequence. A realistic first scope for an illustrative discount approval would have a sales manager approve discounts up to an agreed threshold, a finance reviewer see larger ones, and a rejected request return to the seller with a comment. The thresholds, approver roles and team structure are business decisions. Settle them with sales operations and finance before anyone builds the diagram, because every change to the routing rules later means editing the process and retesting it.
Plan for the parts that go wrong in practice: an approver leaves the company, a task sits unanswered, or a quote is edited after approval. Decide who holds the process when an assignee is missing, whether an edit after approval restarts the flow, and who may act on a task that was reassigned. Confirm in your environment how user tasks appear in the approver's interface and how the process log records the identity of the person who acted, because the audit value depends on those details. Test each path with at least one rejection, one approval and one reassignment before release, using a non-production instance first.
Which approval pattern fits discounts, quotes and contracts
A single approver fits low-value, low-risk decisions such as a small discount off a standard price list. One user task goes to one owner, usually a sales manager, and the process moves forward on approve or ends on reject. The shorter design keeps the process log easy to read, because the whole decision sits in one step.
- Object: a discount line or quote header that carries the requested percentage and a reason code.
- Assignee: a named user or a role-based owner, so the task does not stall on one person's absence.
- Outcome: approve writes the status back to the record and notifies the requester, while reject ends the process with a stated reason.
- Limit: one approver means no second opinion, so set the threshold where your controls owner accepts a single sign-off.
Check that the approver can see the quote and discount fields, and that the process log records who acted and when.
Contracts usually need legal, finance and an executive signatory to approve in a fixed order. A sequential chain creates one user task per stage, and each task starts only after the previous approve action. Each stage can belong to a different team, which matches how contract review is divided in most organizations.
- Stage order: commercial, legal and finance, then the executive signatory, each as a separate user task.
- Gateways: an exclusive gateway after each stage sends approve forward and reject to an end or return path.
- Parallel reviews: where two reviews do not depend on each other, a parallel gateway can shorten waiting time. Confirm how your version's BPMN editor handles this.
- Re-entry: decide whether a legal change restarts the whole chain or only the stage that raised it.
Before building, map each stage to a named owner and list what each reviewer must see, so every task form shows the right fields.
Routing depends on conditions evaluated when the process reaches a gateway. Formula Script is EspoCRM's built-in scripting language and runs in workflows and BPM, so the same expressions can calculate a discount percentage, total contract value or margin and compare the result with an approval matrix. Keeping the formula in one place makes the rule easy to review with the controls owner.
- Discount percent: compare the requested discount with the limit for the sales representative's band.
- Contract value: use the total or annual value field, and document its currency and tax treatment.
- Layered thresholds: order gateway conditions from the highest limit down, so each value lands on exactly one route.
- Default route: define a fallback path so an empty or unexpected value cannot skip approval.
Test each boundary value, including a value exactly on the limit, in a non-production instance, and confirm the syntax against the Formula documentation for your version.
Approvers are usually chosen by team membership, so a change of staff does not require editing the process. EspoCRM's teams and roles control who can see and act on records. Team-based assignment works best when each team represents one approval group and the process selects a member from it.
- Approval groups: create teams such as regional sales managers or legal reviewers, and map each team to one stage.
- Member selection: decide whether the task goes to every member, one assignee or the least loaded member, and confirm which options your edition supports.
- Access: team membership alone does not give access to a record, so check that roles let reviewers open the quote or contract.
- Cover: name a backup approver for each team so tasks do not stall during leave.
Confirm with your administrators who may change team membership, because that controls who can approve.
A reviewer may need changes before saying yes or no. A review action can return the record to the requester with comments, and the design question is whether the process resumes at the same point after resubmission or starts again. That choice shapes what the audit trail shows for each decision.
- Return with comment: a review action sends the task back to the requester with required reason text.
- Resubmission loop: a gateway routes a resubmitted quote to the same stage or to the first stage, depending on the change made.
- Loop limits: cap the number of returns per record or escalate after repeated returns, so the process cannot cycle indefinitely.
- Log: every return, comment and resubmission should appear in the process log with the actor and time.
Ask your process owner which changes must restart the chain, and test a return, a resubmission and a final rejection before go-live.
Configuration options and when each fits
This table compares the main design choices for an approval process in EspoCRM, from how the process starts to how long its history is kept. Read each row as a decision: the fit describes when the option suits a discount, quote or contract workflow, and the trade-off names what you accept by choosing it. Confirm the exact setting names and options against the Advanced Pack documentation for your version before you finalize the design.
| Option | Fit | Trade-off |
|---|---|---|
| Trigger on field change | Discounts or contract values that move to an approval-needed status when a user edits a record | Every edit that meets the condition starts a new process, so guard against repeat starts and duplicate approval requests |
| Manual start | Quotes that a rep sends for review only when they are ready, or ad hoc contract exceptions | Relies on users remembering to start the process, so pair it with a status check before sending the document to a customer |
| Approve and review actions | Approve when a decision authorizes the record to advance, review when a reviewer only needs to comment or check | Review-only steps add a hand-off without a stop, so define what the reviewer must return and how the process proceeds |
| Sequential approvers | Chains such as sales manager then finance, where the second approver needs the first decision | Each step waits on the previous one, so total elapsed time grows with every added approver |
| Parallel approvers | Independent checks such as legal and finance reviewing the same contract at once | Both branches must finish before the record moves on, and conflicting decisions need a defined resolution rule |
| Gateway conditions | Routing by discount percentage, deal value or contract type to different approval paths | Each new threshold adds a branch to test, and formula logic errors can send work to the wrong approver |
| Notification channels | In-app alerts for active users, email for approvers who work outside the CRM for long periods | Email depends on mail delivery being configured correctly, and too many notices lead approvers to ignore them |
| Process log retention | Keeping full process history for audit questions about who approved what and when | Retention is governed by your database and backup policy, so confirm storage growth and purge rules with your team |
How to build an approval process in EspoCRM step by step
This sequence takes a discount, quote or contract approval from a business decision to a tested BPM process that routes records, records each decision and leaves an auditable log. Each step ends with a check so the team knows it can move on.
Confirm the Advanced Pack and plan
Confirm that your EspoCRM instance has the Advanced Pack installed, or that your cloud plan includes it, because Business Process Management and workflows come from that extension. Check the edition and version against the EspoCRM pricing and Advanced Pack pages, and confirm with the vendor that your hosting meets the server requirements in the configuration docs. Your administrator should be able to open the BPMN process designer and see the process settings in the administration area. This step is done when the BPM designer opens for an admin user on a non-production instance.
Define approval rules with the commercial owner
Work with the person who owns pricing and deal terms to write down the approval rules in plain language. Cover which records need approval (for example, a discount above a threshold, a quote above a value or a contract with non-standard terms), who approves at each level, what happens when they reject, and what the sales rep must do to resubmit. Agree the thresholds in writing and keep that document as the source for the build. This step is done when the commercial owner signs off a one-page rule set that someone else could build from.
Create fields and roles for the approval
Add the fields the process needs to the target entity, such as an approval status, a requested discount, an approver and a decision date, using the Entity Manager. Set layouts so reps can submit and approvers can see the decision fields only. Create the approver roles and assign them to teams or users, and restrict who can edit the status field directly so approvals cannot be bypassed by editing the record. This step is done when a test user with the sales role can enter a discount, and a test user with the approver role can see the fields but cannot change the status manually.
Build the BPM process with user tasks and gateways
In the BPM designer, model the flow: a start event on submission, a user task assigned to the approver role, an exclusive gateway that branches on the decision, and end events for approved and rejected outcomes. Use formula script to set the next approver from the amount or the discount, and add a notification step so the approver is alerted. Keep the model simple at first and add escalation levels only once the basic path works. This step is done when the diagram validates and the process can be published on the test instance.
Test with sample records and check the paths
Create sample quotes or discounts that cover each path: below threshold, above threshold, approved at the first level, rejected and resubmitted. Run each one through the process and confirm the record status, the assigned approver and the notification at every step. Record the expected result for each path before you run it so the test is a comparison, not an opinion. This step is done when every path produces the expected status and no record can reach an end state without a recorded decision.
Confirm the process log output
Open the process log for each test instance and confirm that it records the start, each user task, each decision, the approver identity and the timestamps. Check that the log is retained long enough for your audit needs and that only admins can view it. Also confirm the record's activity stream shows the status change. Ask your compliance lead to review a sample log against the rule set from the second step. This step is done when the log for every test path matches the agreed rules and the compliance lead accepts the evidence format.
Promote the process with a rollback plan
Move the entity changes and the BPM process to production using your normal change process, and keep the export of the tested configuration so the same build can be reapplied. Confirm with the vendor and your administrator how processes and customizations are exported and imported in your version, because this affects repeatability. Decide who can publish process changes in production and record that decision. This step is done when the process runs on production with a single test quote approved by the commercial owner, and the rollback steps are written down and reviewed.
Who can approve, and how to keep approvals trustworthy
An approval process is only as credible as the people who can act in it and the accounts they use. The cards below cover who gets approval tasks, which accounts they should use, how sign-in is protected, and who is allowed to change the process itself.
Scope approval tasks by role and team
Assign each BPM user task to a role or team that only designated approvers belong to, rather than to a named person who may leave or change jobs. Discount approvals, for example, can go to a sales director team, while contract approvals go to legal. Before go-live, log in as a standard user from each team and confirm that tasks and records outside that approval path are not visible. Check that approvers can see the quote or contract they must decide on, but cannot edit it after submission.
Keep admin accounts out of approvals
Approvers should never act through an admin account. An admin can change records, workflows and permissions, so approving under that identity blurs who decided what and weakens the audit trail. Give each approver a regular user account with the minimum role needed to act on tasks. Keep administrator accounts for configuration and recovery, and document which accounts are allowed to do each.
Enforce password and 2FA policy
Set a password policy that meets your identity standard, and require two-factor authentication for every account that can approve spend or contracts. Limit auth token lifetime so that an abandoned browser session cannot be used to approve a discount later. Disable password recovery for admin accounts so that an attacker cannot reset an admin and then edit the approval route. Confirm each setting in the administration panel and record it as part of your control evidence.
Use OIDC sign-in with its 2FA limits
If approvers sign in through your identity provider with OpenID Connect, EspoCRM's own two-factor authentication is not compatible with that flow, so the second factor must come from the identity provider. Decide whether first-login user creation is allowed and map identity provider groups to EspoCRM teams so that team membership follows the directory. Test a fallback login path and confirm that backchannel logout removes an approver's session when access is revoked. Ask your identity team to confirm which MFA methods the provider enforces for approvers.
Restrict who can edit the process
Editing a BPM process changes what happens to every future approval, so limit workflow and process design rights to a small group of administrators or process owners. Require that changes to gateway conditions, approval thresholds and approver assignments go through a review and a test instance first. Keep a record of who published each version of the process. Ask your team to confirm which roles can open the process editor in your installed version.
Restrict approval access by network
If approvers work from fixed offices or a corporate VPN, restrict access to the EspoCRM instance by IP address so that approval actions cannot be taken from unmanaged networks. Pair this with the session and password controls rather than relying on the network alone, since mobile and remote approvers may need access from outside the office. Confirm with your network team how the allowlist will be maintained when approvers change, and who can approve an exception.
Questions buyers ask about EspoCRM approval processes
What drives the build effort for EspoCRM approval processes?
The main driver is how many distinct approval paths exist and how many decisions each one has to make. A discount approval with two thresholds and one approver is a small build. A quote process that routes by region, product line, deal size and legal review, with parallel approvers and rework loops, is a much larger one. Other drivers include the number of custom fields and entities the rules read, how many notifications and audit requirements apply, and whether approvals must trigger changes to quotes, contracts or records. Ask any partner to break the quote down by process path, not by a single total.
Can our own team build EspoCRM approval processes without outside help?
Yes, if your team has an administrator who can work in the Entity Manager, layouts, formula scripts and the Advanced Pack's BPMN 2.0 process engine, and someone who owns the approval policy. The harder parts are usually design decisions rather than tooling: defining thresholds, deciding who can override a decision, and setting what the audit trail must show. Teams without BPM experience often find the first process takes longer than expected, because gateways, user tasks and error paths need testing. An outside partner is most useful for design review, the first process build and handover, and it is worth asking whether the work includes training your administrators.
What does the work need from our side before the build starts?
Three inputs shape almost every approval build. The first is an approval matrix: the thresholds, the approvers for each band, the escalation rule when someone is unavailable, and the outcomes allowed (approve, reject, return for changes). The second is a role model that matches those approvers, including teams and any permission limits on who can see or act on records. The third is sample data: realistic quotes, discounts or contracts with the fields the rules read, so the process can be tested against real edge cases. Missing any of these usually adds rework late in the project.
How long does an approval process build take compared with the number of rules?
Duration grows with the number of rules, branches and integrations, but not in a straight line. Each additional approval path adds design, build and test time, and interactions between paths (for example, a discount that also changes contract terms) add more. No duration is given here because it depends on your scope and environment. Ask for a timeline tied to a written list of process paths, with testing and sign-off included, and check whether the plan assumes your approval matrix is final before build begins.
How are changes to approval rules handled after go-live?
Approval rules change as pricing, policy and org structure change, so plan for change control from the start. In practice this means versioning process definitions, testing changes against sample records in a non-production instance, and keeping a record of who approved each rule change. Running processes may need a decision on whether open approvals finish under the old version or move to the new one. Ask whether ongoing changes are covered by a retainer or billed as separate scoped work, and who on your team can make small threshold changes without a partner.
What does EspoCRM Cloud pricing cover compared with self-hosting costs?
EspoCRM Cloud is priced per user per month: 15 US dollars on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), according to the EspoCRM pricing page. The Advanced Pack, which provides the BPM and workflow engine used for approvals, is included in all cloud plans. The open-source edition can be downloaded and self-hosted for free, according to the same page, but self-hosting moves costs to your infrastructure: servers, backups, upgrades, TLS and monitoring, plus the staff or partner time to run them. Compare the per-user subscription against those recurring costs and the one-time build effort, and confirm with the vendor which features and limits apply to your chosen plan.
Keeping approval processes working through EspoCRM upgrades
Approval processes built with BPM user tasks depend on the Advanced Pack's process engine and on how EspoCRM evaluates the formulas, gateways and task actions inside each process. A major release can change any of those behaviors, so every upgrade needs a regression test of the approval flows before the new version goes live. EspoCRM 10.0.0 was released on July 2, 2026, according to the espocrm/espocrm GitHub releases page, and that release is the point where your approval inventory should be checked against the new version. Confirm the Advanced Pack version that matches your target release, since the extension and the core must move together.
Start the regression pass by listing every approval process in production: its process definition, the entity it runs against (discount requests, quotes or contracts), the user tasks with approve and review actions, the gateway conditions and the notification templates. Open approvals deserve particular attention. A request started under the old version may be waiting on a task that the new process model handles differently, so test a copy of a live instance with representative in-flight records, not only new submissions. Confirm the access rules for approver roles and the audit entries in the process log still show who acted and when.
Plan for the upgrade path itself. The EspoCRM security documentation notes that upgrading through the UI is disabled by default as of version 10.0, so the upgrade runs through the command line on a staging copy first and then on production. Schedule the change in a window where no approvals are pending, or drain the queue beforehand, and keep a tested backup of the database and files before you begin. Ask your implementation partner or internal team to document the rollback steps, because a failed approval step discovered after go-live is harder to correct than one found in staging.
How DeployOpen scopes and delivers EspoCRM approval processes
DeployOpen plans, builds, tests and documents EspoCRM approval processes inside your own infrastructure, starting from the discount, quote or contract rules your sales and finance teams already follow. Each engagement is fixed-scope, with the approval paths, roles and deliverables agreed in writing before build work starts.
How we scope
- We map which records need approval, such as discounts, quotes or contracts, and the thresholds that trigger each path.
- We list the approver roles, teams and fallback approvers, and confirm them against your existing EspoCRM roles and teams.
- We agree in writing which notifications, decision gateways and audit fields are in scope and which are excluded.
How we build
- We build the BPM user tasks with approve and review actions, then wire gateways so each decision routes to the correct next step.
- We configure notifications to approvers and requesters, and record each decision in the process log with the actor and timestamp.
- We test rejection, reassignment and missing-approver cases on a non-production instance before anything reaches your users.
How we hand over
- You receive the process models, Formula Script logic, role definitions and configuration documented against the agreed scope.
- We walk your administrators through the process log, how to change thresholds and how to add or remove approvers safely.
- We provide a test record set and checklist so your team can repeat the verification after future changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the approval workload you need covered.
- We plan process changes alongside EspoCRM version upgrades, so approval logic is checked against each new release before go-live.
- Ask any partner to confirm the support hours, response terms and upgrade scope in writing before you sign.
