# Organizational Unit structure

<nav id="TableOfContents">
      - <a href="#integrator-organizational-units">Integrator Organizational Units</a>
              <li><a href="#example">Example</a>

          </li>
    - <a href="#customer-organizational-units">Customer Organizational Units</a>
              <li><a href="#onboarding">Onboarding</a>

        - <a href="#examples">Examples</a>
                      <li><a href="#general-case">General case</a>

            - <a href="#multiple-calendar-hosts">Multiple calendar hosts</a>

            - <a href="#per-business-unit">Per-business unit</a>

                  </li>
          </li>
    - <a href="#integrating-against-organizational-units">Integrating against Organizational Units</a>

  </nav>
# What is an Organizational Unit?
Within Cronofy, an Organizational Unit is a container within which various
things can be managed. From a permissions perspective it creates a hard boundary
to other entities within Cronofy.

Though various mixtures are possible, we typically see two "shapes" of
Organizational Unit:

- Integrator - created for the management of an integration

- Customer - created to enable a company's employees to schedule via Cronofy

## Integrator Organizational Units
Integrator Organizational Units primarily exist to manage the Cronofy
applications that the integrator is building against.

Members of the Organizational Unit will be people from IT, operations, and
software development who need access to one (or more) of the applications
falling under the Organizational Unit's jurisdiction.

Access can be granted at the Organizational Unit level, for example granting the
Ops Admin access to all Applications, or at the individual level, for example
providing the Developer access only to the Staging and Development applications.

### Example
```mermaid
flowchart LR
  subgraph OU[Organizational Unit]
    direction LR

    subgraph apps[Applications]
      prod-app[Production]
      staging-app[Staging]
      dev-app[Development]
    end

    subgraph members[Members]
      ops[Ops Admin]
      eng-man[Engineering Manager]
      developer[Developer]
    end
  end```
## Customer Organizational Units
Customer Organizational Units primarily exist to manage the scheduling setup of
a whole company, or a specific business unit within a wider company. Such
configuration starts with calendars, but will often cover video conferencing and
other integrations that need to be configured to support their scheduling
workflows.

Integrations can be provided directly by Cronofy, but also by integrators using
Cronofy's API.

For this configuration, access is generally only role-based. The Ops Admin has
the ability to manage the various integrations, setting up calendar access,
configuring provisioning rules for members, and such like.

The Scheduling Coordinator would be given the ability to manage scheduling
rules, groups, and perform scheduling operations on behalf of other members.

The general employees will usually have much more restricted access, for example
seeing the events that have been scheduled, though this is rarely used as their
calendar is the easiest source of this information.

### Onboarding
Onboarding for employees can take many forms:

- Manually, on a member-by-member basis

- Automatic, based on presence within an organization directory

- Automatic, but based on a group within an organization directory

For SMEs we usually see a straightforward "one Organizational Unit for everyone"
approach, often with automatic onboarding for new employees based on them being
added to the organization's directory.

For larger companies, the picture is more mixed. Many still take the "one
Organizational Unit" approach, but we also see Organizational Unit per business
unit, per function, function within business unit, and even for specific
projects. These are all supported by Cronofy, allowing people to draw the
boundary lines where they see fit.

### Examples
#### General case
```mermaid
flowchart LR
  subgraph OU[Organizational Unit]
    direction LR

    subgraph integrations[Integrations]
      calendar[Calendar provider]
      conferencing[Conferencing provider]
      integrator-app[Integrator application]
    end

    subgraph members[Members]
      ops[Ops Admin]
      coordinator[Scheduling Coordinator]
      employee-a[Employee A]
      employee-b[Employee B]
      employee-x[Employee ...]
    end
  end```
#### Multiple calendar hosts
```mermaid
flowchart TB
  subgraph OU[Organizational Unit]
    direction TB

    subgraph integrations[Integrations]
      calendar-a[Microsoft 365 Calendars]
      calendar-b[Google Calendars]
    end

    subgraph members[Members]
      ops[Ops Admin]
      coordinator[Scheduling Coordinator] -.-> calendar-a
      employee-a[Employee A] -.-> calendar-a
      employee-b[Employee B] -.-> calendar-b
      employee-x[Employee ...] -.-> calendar-b
    end
  end```
#### Per-business unit
```mermaid
flowchart TB
  subgraph sales-OU[Sales OU]
    direction TB

    subgraph sales-integrations[Integrations]
      sales-calendar[Microsoft 365 Calendars]
      sales-conferencing[Zoom]
      sales-integrator-app[Hubspot]
    end

    subgraph sales-members[Members]
      sales-ops[Ops Admin]
      sales-coordinator[Sales Manager]
      sales-employee-a[Account Exec A]
      sales-employee-b[Account Exec B]
      sales-employee-x[Account Exec ...]
    end
  end

  subgraph support-OU[Support OU]
    direction TB

    subgraph support-integrations[Integrations]
      support-calendar[Microsoft 365 Calendars]
      support-conferencing[Zoom]
      support-integrator-app[Zendesk]
    end

    subgraph support-members[Members]
      support-ops[Ops Admin]
      support-coordinator[Support Manager]
      support-employee-a[Support Agent A]
      support-employee-b[Support Agent B]
      support-employee-x[Support Agent ...]
    end
  end```
## Integrating against Organizational Units
For an integration to be active for an customer Organizational Unit, there needs
to be an authorization connecting their Organizational Unit to an integrator's
application.

This is achieved by an administrator of the customer's Organizational Unit going
through an [Organization Connect](/developers/authorization/organization-connect/index.md)
OAuth-based authorization flow. The initiating Cronofy application then receives
an access and refresh token it can use to perform permitted operations on the
customer Organizational Unit's behalf via Cronofy's platform.

```mermaid
flowchart TB
  app[Integrator Application]

  app --> ou-a-auth[Authorization] -.-> ou-a[Customer Organizational Unit]```
The integrator's application then maintains a separate authorization for each
customer Organizational Unit:

```mermaid
flowchart TB
  app[Integrator Application]

  app --> ou-a-auth[Authorization] -.-> ou-a[Customer A]
  app --> ou-b-auth[Authorization] -.-> ou-b[Customer B]
  app --> ou-c-auth[Authorization] -.-> ou-c[Customer C]
  app --> ou-d-auth[Authorization] -.-> ou-d[Customer D]
  app --> ou-x-auth[Authorization] -.-> ou-x[Customer ...]```
In the case where a company has multiple Organizational Units, the integrator's
application must obtain a separate authorization for each one:

```mermaid
flowchart TB
  app[Integrator Application]

  app --> ou-a-auth[Authorization] -.-> ou-a[Customer A Sales]
  app --> ou-b-auth[Authorization] -.-> ou-b[Customer A Support]
  app --> ou-c-auth[Authorization] -.-> ou-c[Customer A Hiring]```


---
[Read in HTML](/developers/organizational-unit-structure/)