Skip to main content

Approvals

The Approvals module is Hana's human-in-the-loop decision surface for automation workflows.

It is commonly used to gate actions in:

  • Zapier flows (for example, "draft -> approval -> post/send")
  • Hana API workflows (for example, create approval in backend process, then poll for decision)

What You Can Do​

  • List approval requests in a paginated table.
  • Open full approval details (content, links, images, approver statuses).
  • Share approval deep links with teammates.
  • Perform approver actions (APPROVED / REJECTED) when you are an allowed approver.

Approval Lifecycle​

  1. A workflow creates an approval request (via Hana API or integrated automation).
  2. Approvers are notified (email and optionally a Google Chat card when googleChatSpaceId is provided).
  3. Approvers act from dashboard/chat card.
  4. Workflow reads approval status and branches:
    • proceed path
    • reject/fallback path

What Gets Stored Per Approval​

  • content: the decision text to review
  • approvers[]: allowed approver user IDs
  • approverActions: action map per approver (APPROVED / REJECTED / NO_ACTION)
  • defaultAction: fallback when no decision is made before expiry
  • expiryDate
  • optional links[], images[], and googleChatSpaceId

Key Behaviors​

  • Each approval shows approver-level status chips for transparent state.
  • Detail dialogs can be opened directly via ?approvalId= URL query.
  • Action availability depends on approver identity, organization, and expiry.

Use approvals as a gate before irreversible steps.

Example:

  1. Trigger: New record/content generated (CRM/Notion/Sheet/form).
  2. Action: Create Hana approval request with:
    • clear content
    • 1+ approvers
    • suitable expiryDate
    • conservative defaultAction (usually REJECTED)
  3. Wait/poll: Fetch approval status from Hana API.
  4. Branch:
    • If approved condition met -> continue (post/publish/send)
    • Else -> stop/escalate/notify owner

Hana API Pattern​

Approvals for API integrations use these endpoints:

  • POST /v1/expose-api/approval/create-approval
  • GET /v1/expose-api/approval/{approvalId}
  • GET /v1/expose-api/approval

Decisioning is based on approverActions + expiryDate + defaultAction.

Practical evaluation options:

  • Any-approver model: proceed when at least one approver sets APPROVED.
  • All-approver model: proceed only when every approver has APPROVED.
  • Strict rejection model: immediately fail when any approver sets REJECTED.
  • Timeout fallback: if expired with unresolved decisions, apply defaultAction.

Invocation/Automation Examples​

Use case: Marketing publish gate
- Create approval for campaign copy with approvers [Legal Lead, Marketing Lead]
- defaultAction=REJECTED
- On approved: publish
- On rejected/timeout: move to revision queue
Use case: External email gate
- Generate outbound email draft with Hana
- Create approval for manager
- Only send if manager action is APPROVED before expiry

Typical Workflow​

  1. Open Approvals.
  2. Review pending requests and approver states.
  3. Share link with required reviewers if needed.
  4. Execute action and confirm updated status chips.
  5. Let automation continue along the correct branch.

Good Practices​

  • Keep approval content explicit and decision-ready.
  • Set realistic but short expiryDate windows.
  • Prefer defaultAction=REJECTED for high-risk automations.
  • Always include supporting links/images for faster review.
  • Avoid broad approver lists when one accountable approver is enough.
  • Store and monitor approvalId in your automation logs for traceability.

See also​

Last updated on by nav