Approver Types (User, Role, Record Owner, Custom Attribute)

Short Description Advanced approval workflows specify approvers in one of four ways. This article explains each and when to use them.

What this article answers

• The four approver types Hive9 supports.
• How each resolves to a specific person at runtime.
• When to use which type.

The four approver types

[SCREENSHOT NEEDED — Workflow configuration screen with approver type dropdown]

User

A specific named user. The workflow always routes to that person.

Pros:

• Predictable — you know exactly who's signing.
• Good for executive sign-off where the CFO or VP must personally approve.

Cons:

• Single point of failure — if the user is on vacation, the workflow stalls until they return (or until an admin reassigns).
• Doesn't adapt as people change roles.

Use when: the approver must be a specific person and won't change often.

Role

Any user with the specified role can act. The workflow surfaces the approval to all role-holders; the first to act resolves it.

Pros:

• Resilient to vacations and turnover.
• Scales as your team grows.

Cons:

• Less predictable — you don't know who will actually approve.
• If the role has many members, accountability for the specific approval is diffused.

Use when: you want capacity coverage, and any qualified person can sign.

Record Owner

The user who owns the object being approved. The workflow routes to that person dynamically.

Pros:

• Built-in personalization — each tactic routes to its owner.
• Useful as a self-acknowledgment step or as a launch point for a manager-of-owner approval chain.

Cons:

• The owner is approving their own work, which limits its value as a governance gate. Often used at the start of a multi-stage chain.

Use when: an owner-acknowledgment step is required, or as a foundation for a subsequent manager approval.

Custom Attribute

A user referenced through an attribute on the tactic itself — for example, a custom attribute named "Approver" that holds a user reference. The workflow looks up the attribute's current value and routes to that user.

Pros:

• Conditional routing — different tactics route to different approvers based on the attribute value.
• Highly flexible.

Cons:

• Requires the attribute to be populated correctly. If empty, the workflow may stall.
• Adds maintenance overhead — someone has to keep the attribute values current.

Use when: approval routing varies per tactic, region, business unit, or other attribute-driven criterion.

Combining approver types

Advanced workflows can mix approver types across stages:

• Stage 1: Record Owner — owner acknowledges.
• Stage 2: Role (Finance Manager) — finance signs off.
• Stage 3: User (CFO) — only on tactics over a threshold.

You can also have multiple approvers per stage with all-or-any logic.
 

Common questions

What happens if the resolved approver has Can Approve = No on the team? The approver isn't eligible, so the workflow can't route to them. Either fix the team membership (set Can Approve = Yes) or update the workflow to pick a different approver.

Can I have a backup approver? Use Role-based approvers, or set up a workflow stage with multiple approvers requiring just one to act.

What if the Custom Attribute referenced is blank on a tactic? The workflow can't resolve to a person and the approval typically stalls. Either populate the attribute before submitting, or design the workflow with a fallback.

Are these types available in Basic workflows? Basic workflows have a simpler model — usually team-based routing. Advanced workflows expose all four types.
 

Related articles

• Basic vs Advanced Approval Workflows
• Custom Attribute Group approval flow
• My Approvals — what shows up and why
• Who can approve tactics on a team?