Features
Approvals
Some terms need a person's sign-off before a contract moves on. In Lexnus, a playbook rule decides when sign-off is needed and which group gives it. The request reaches the approvers by itself. Until they approve, the contract cannot be sent for signature.
How approvals work
Set up an approval group
An approval group is the set of people who can sign off. Creators and Admins set groups up under Settings → Account → Workflow → Approval Groups. Each group either needs one member to approve, or needs every member to approve.
Add people by name, or describe them with conditions — role, email, name, title or workspace — and let membership follow. "Preview matches" shows who a condition picks up before you save. Membership refreshes within about 15 minutes of a change.
Write the rule that asks for approval
Every rule in a playbook has an escalation: Flag marks the contract for review and never blocks it. Require approval sends it to a group. Reject blocks it outright.
A Require approval rule fires when the contract's fields match its condition — a liability cap above twice the contract value, say. Or it can ask for a manual review of every version. A playbook cannot be published while a Require approval rule has no group.
The request reaches the approvers
When an analysis finds a rule that needs approval, Lexnus opens a request for that rule and that version of the contract. Approvers hear about it in the application, by email, and in Slack if your account has connected it. They find it on the Approvals page, on their dashboard and beside the contract itself.
Approve, or send it back
The approver reads the finding behind the request and decides. "Approve this rule" signs it off. "Request changes" sends the contract back to draft, with a reason. In Slack, the same request arrives with Approve and Reject buttons.
One rejection is enough, even in a group where everyone must approve. The contract returns to draft, and the owner sees who declined and why. The answer is a new version, which is checked again.
Nothing is signed without it
Before a contract is sent for signature or marked active, Lexnus checks its latest version: every required approval in place, no rule that cannot be approved, nothing left unresolved. If the check cannot be completed, the answer is no. The one exception is a contract already signed elsewhere, filed in Lexnus as signed.
What you get
- Rules decide, not habits — Whether a contract needs approval is the playbook's answer. Whichever way the analysis was started — the application, Slack, the API or an AI agent — the same rule raises the same request.
- Groups that keep themselves current — Condition-based membership follows role, title and workspace, so a new hire in finance is an approver without anyone remembering to add them.
- One or all — Each group needs either any one member or every member to approve.
- Decide from Slack — Approve and Reject buttons in a direct message, with the rule, the value it found and the clause it came from. Reject asks you to confirm.
- Decisions per version — An approval carries over to a new version only when the rule, the fields it read and the appendices are unchanged. Change any of them and the request is raised again. Manual reviews are asked for every version.
- Events for your systems — Webhooks for "Approval requested" and "Approval decided" let your own tools follow along.
- A record of every decision — Requests and decisions are written to the audit log with the rule revision that raised them.
Who uses approvals
Legal writes the rules and sets up the groups. Deciding what needs sign-off is a policy decision, and it lives in the playbook.
Approvers — finance, leadership, a regional lead — decide when asked. They do not need to know the playbook. The request tells them what the rule found and where.
The person moving the contract sees what is waiting, on whom, and what to do if it comes back.