> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hopae.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizations, Apps & Workflows

> How Hopae Connect is organized — and where you configure a verification

## Overview

Hopae Connect organizes everything into a three-level hierarchy. Each level nests inside the one above it:

**Organization → Application → Workflow**

```mermaid theme={null}
graph TD
  O["Organization<br/>(your company)"]
  O --> A1["Application<br/>(a product)"]
  O --> A2["Application<br/>(another product)"]
  A1 --> W1["Workflow<br/>(a verification)"]
  A1 --> W2["Workflow"]
  A2 --> W3["Workflow"]
```

| Level | Maps to | What it is |
| - | - | - |
| **Organization** | Your company | The tenant that owns everything. Members, billing, and organization API keys live here. |
| **Application** | A product | One product or integration. Holds its OIDC credentials, activated providers, company details, and custom domain. |
| **Workflow** | A verification | One verification configuration: which data to request, which providers to offer, how it looks, and any decision logic. |

Most day-to-day setup happens at the **workflow** level. The sections below walk down the hierarchy, then detail what a workflow controls.

## The three levels

### Organization — your company

An organization is your company's tenant in Hopae Connect, the top of the hierarchy. It owns everything beneath it — applications, members, billing, and the **organization-level API keys** used to call the [Workspace API](/api-reference/workspace/introduction). One organization can hold many applications.

### Application — a product

An application (often shortened to "app") represents a single product or integration. It is the hub where most setup lives:

* **OIDC credentials** — client ID, client secret, and redirect URIs.
* **Provider activation** — turning each eID provider on for the app. See [Provider Activation](/guides/concepts/activations).
* **Company information** — legal details used to prefill provider activation requests.
* **Custom domain** — serve the verification UI from your own domain. See [Custom Domain](/guides/concepts/custom-domain).
* **Default branding** — the app name and logo that workflows can inherit.
* **Webhooks** — where Hopae notifies your system of events.

Every application exists independently in both [Sandbox and Production](/guides/concepts/environments). An application can hold many workflows (up to 100) and always has one marked as the **default**.

### Workflow — a verification

A workflow is a single verification configuration — the leaf of the hierarchy and the unit you run when you start a verification. It decides **what a verification asks for and how it behaves**, which is covered next.

## What a workflow configures

Each workflow bundles the settings for one verification experience:

| Setting | What you control |
| - | - |
| **Channel** | How the verification runs — `oidc` (a hosted OIDC webview) or `api` (direct REST integration). See [Integration Methods](/guides/integration-methods). |
| **Claims** | Which normalized user claims the verification requests (for example `name`, `birthdate`), plus any provider-specific claims. See [Normalized User Data](/guides/verifications/normalized-user-data). |
| **Providers** | Which activated providers this workflow offers (see note below). |
| **Branding** | A display name and logo for the verification UI, or inherit the app's branding. |
| **Decision logic** | Optional steps that gate or branch the flow — see [Decision graph](#decision-graph-advanced). |

<Note>
  **Providers are gated twice.** A provider must first be **activated for the application** — a one-time setup, see [Provider Activation](/guides/concepts/activations). Every activated provider is then offered by every workflow *by default*; a workflow can opt a provider out so it is not shown in that particular flow. The workflow setting controls visibility, not activation.
</Note>

<Note>
  Branding here is a display name and logo (or inheriting the app's). The domain that serves the verification UI is set at the app level — see [Custom Domain](/guides/concepts/custom-domain).
</Note>

## The default workflow

Every application is created with a ready-to-run **default workflow** — a straight `request → verification → response` path that requests `name`, `given_name`, `family_name`, and `birthdate`. You can start verifications immediately, without building anything.

When you start a verification without naming a workflow, the app runs its default. Create or customize workflows only when you need different data, providers, branding, or logic. Change which workflow is the default in the Console.

## Decision graph (advanced)

By default a workflow runs a single straight line — request the verification, return the result. When you need conditional behavior, a workflow is also a small **graph of nodes**: you insert steps between the verification and the response to gate or branch the flow.

Each node has an `id`, a `type`, an optional `next` (the id of the following node — or, for an `if` node, a list of conditional routes), and a type-specific `config`.

| Type | Purpose | Key `config` |
| - | - | - |
| `request` | Workflow entry point. | — |
| `verification` | Runs the identity verification step. | `channel`, `claims`, `providers`, `branding` |
| `check-min-loa` | Gates the flow on a minimum Level of Assurance. | `minLoa` (number, 1–5) |
| `check-claim` | Requires that specific claims exist in the output. | `claimChecks` (array of `{ source, field }`) |
| `evaluate` | Evaluates conditions and stores the boolean result under a named field. | `outputField`, `conditions` |
| `if` | Branches the flow based on conditions. | uses `next` as a list of routes |
| `response` | Terminal node — finalizes the result. | — |

The `verification` node carries the channel, claims, providers, and branding from the section above. The other node types are optional — add them only when you need an assurance gate, a required-claim check, or branching.

## How a workflow runs

When a verification session starts, Hopae Connect runs the chosen workflow — or the app's default — from its `request` node to a `response` node. The `verification` node produces the UserInfo payload described in [Return Data](/guides/verifications/return-data-model); any downstream nodes read that payload to gate or branch the flow before it reaches `response`.

## Next Steps

<CardGroup cols={2}>
  <Card title="Provider Activation" icon="toggle-on" href="/guides/concepts/activations">
    Turn eID providers on for your app
  </Card>

  <Card title="Level of Assurance" icon="shield-check" href="/guides/verifications/assurance">
    Understand the LoA values used by check-min-loa
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.