Organizational Unit structure

Table of contents

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 #

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 #

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 #

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 #

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 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.

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:

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:

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]