# Organizational Unit structure # 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 **Integrator Organizational Unit** Diagram of an integrator Organizational Unit holding three applications, Production, Staging, and Development, and three members, an Ops Admin, an Engineering Manager, and a Developer. ```mermaid flowchart LR subgraph Organizational_Unit[Organizational Unit] direction LR subgraph Applications direction TB Production Staging Development end subgraph Members direction TB Ops_Admin[Ops Admin] Engineering_Manager[Engineering Manager] Developer end end ``` - The Organizational Unit holds the integrator's applications: Production, Staging, and Development. - It also holds its members: an Ops Admin, an Engineering Manager, and a Developer. ## 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 **Customer Organizational Unit** Diagram of a customer Organizational Unit holding its integrations, a calendar provider, a conferencing provider, and an integrator's application, and its members, an Ops Admin, a Scheduling Coordinator, and the employees. ```mermaid flowchart LR subgraph Organizational_Unit[Organizational Unit] direction LR subgraph Integrations direction TB Calendar_provider[Calendar provider] Conferencing_provider[Conferencing provider] Integrator_application[Integrator application] end subgraph Members direction TB Ops_Admin[Ops Admin] Scheduling_Coordinator[Scheduling Coordinator] Employee_A[Employee A] Employee_B[Employee B] Employee[Employee ...] end end ``` - The Organizational Unit holds the company's integrations: a calendar provider, a conferencing provider, and an integrator's application. - It also holds its members: an Ops Admin, a Scheduling Coordinator, and employees A, B, and so on. #### Multiple calendar hosts **Organizational Unit with multiple calendar hosts** Diagram of a customer Organizational Unit with Microsoft 365 and Google calendars, where the Scheduling Coordinator and Employee A use Microsoft 365 and Employee B and other employees use Google. ```mermaid flowchart TB subgraph Organizational_Unit[Organizational Unit] direction TB subgraph Members direction LR Ops_Admin[Ops Admin] Scheduling_Coordinator[Scheduling Coordinator] Employee_A[Employee A] Employee_B[Employee B] Employee[Employee ...] end subgraph Integrations direction LR Microsoft_365_Calendars[Microsoft 365 Calendars] Google_Calendars[Google Calendars] end end Scheduling_Coordinator -.-> Microsoft_365_Calendars Employee_A -.-> Microsoft_365_Calendars Employee_B -.-> Google_Calendars Employee -.-> Google_Calendars ``` - The Organizational Unit holds two calendar integrations, Microsoft 365 Calendars and Google Calendars, and its members. - The Scheduling Coordinator's calendar is in Microsoft 365. - Employee A's calendar is in Microsoft 365. - Employee B's calendar is in Google. - Other employees' calendars are in Google too. - The Ops Admin isn't connected to a calendar in this example. #### Per-business unit **Organizational Unit per business unit** Diagram of a company with separate Sales and Support Organizational Units, each with its own calendars, conferencing, and integrator application, and its own members. ```mermaid flowchart TB subgraph Sales_Organizational_Unit[Sales Organizational Unit] direction TB subgraph Integrations direction LR Microsoft_365_Calendars[Microsoft 365 Calendars] Zoom HubSpot end subgraph Members direction LR Ops_Admin[Ops Admin] Sales_Manager[Sales Manager] Account_Exec_A[Account Exec A] Account_Exec_B[Account Exec B] Account_Exec[Account Exec ...] end end subgraph Support_Organizational_Unit[Support Organizational Unit] direction TB subgraph Integrations_2[Integrations] direction LR Microsoft_365_Calendars_2[Microsoft 365 Calendars] Zoom_2[Zoom] Zendesk end subgraph Members_2[Members] direction LR Ops_Admin_2[Ops Admin] Support_Manager[Support Manager] Support_Agent_A[Support Agent A] Support_Agent_B[Support Agent B] Support_Agent[Support Agent ...] end end ``` - The Sales Organizational Unit holds Microsoft 365 Calendars, Zoom, and HubSpot as its integrations. - Its members are an Ops Admin, a Sales Manager, and Account Execs A, B, and so on. - The Support Organizational Unit holds Microsoft 365 Calendars, Zoom, and Zendesk as its integrations. - Its members are an Ops Admin, a Support Manager, and Support Agents A, B, and so on. ## 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](https://docs.cronofy.com/developers/temporal-grid/connectivity/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. **Authorizing access to a customer Organizational Unit** Diagram of an integrator's application connected to a customer Organizational Unit through an authorization. ```mermaid flowchart TB Integrator_Application[Integrator Application] Integrator_Application --> Authorization -.-> Customer_Organizational_Unit[Customer Organizational Unit] ``` - The integrator's application holds an authorization. - The authorization gives it access to the customer Organizational Unit. The integrator's application then maintains a separate authorization for each customer Organizational Unit: **An authorization for each customer** Diagram of an integrator's application connected to customers A, B, C, D, and more, each through its own authorization. ```mermaid flowchart TB Integrator_Application[Integrator Application] Integrator_Application --> Authorization -.-> Customer_A[Customer A] Integrator_Application --> Authorization_2[Authorization] -.-> Customer_B[Customer B] Integrator_Application --> Authorization_3[Authorization] -.-> Customer_C[Customer C] Integrator_Application --> Authorization_4[Authorization] -.-> Customer_D[Customer D] Integrator_Application --> Authorization_5[Authorization] -.-> Customer[Customer ...] ``` - The integrator's application holds a separate authorization for each customer Organizational Unit. - One authorization gives it access to Customer A's Organizational Unit. - Another gives it access to Customer B's, and likewise for Customers C and D and any further customers. In the case where a company has multiple Organizational Units, the integrator's application must obtain a separate authorization for each one: **An authorization for each of a customer's Organizational Units** Diagram of an integrator's application connected to Customer A's Sales, Support, and Hiring Organizational Units, each through its own authorization. ```mermaid flowchart TB Integrator_Application[Integrator Application] Integrator_Application --> Authorization -.-> Customer_A_Sales[Customer A Sales] Integrator_Application --> Authorization_2[Authorization] -.-> Customer_A_Support[Customer A Support] Integrator_Application --> Authorization_3[Authorization] -.-> Customer_A_Hiring[Customer A Hiring] ``` - The integrator's application holds a separate authorization for each of Customer A's Organizational Units. - One authorization gives it access to Customer A's Sales Organizational Unit. - Another gives it access to Customer A's Support Organizational Unit. - A third gives it access to Customer A's Hiring Organizational Unit. --- [Read in HTML](https://docs.cronofy.com/developers/temporal-grid/organizational-unit-structure/)