Role Template Design Structure

Published Date: May 1, 2026 | Last Updated: May 13, 2026

Overview

Role Templates are the mechanism through which Tello IAM manages User access. Each template defines a set of permissions across one or more connected integrations. When a Role Template is assigned to a User, Tello IAM enforces those permissions in every application the template covers — provisioning what is defined and removing what is not.

This article covers how to design a Role Template structure: which templates to create, how to scope them, and how to map them to the organization's HR roles. For instructions on building and managing templates in the platform, see Role Template Management.

How Role Templates work

Before any Role Template is assigned, Tello IAM observes access — detecting and displaying what each User holds in connected applications without controlling it. When a Role Template is assigned to a User, that changes. Tello IAM takes over as the system of record for that User's permissions in every application the template covers.

Important: Assigning a Role Template to a User fully overrides that User's previously detected permissions in every application the template covers. This is not a merge — it is a replacement. Any access the User held that is not included in the assigned template is removed at the time of assignment. Templates must be complete representations of what a User in a given function should hold before they are assigned.

Design approaches

Role Templates are flexible by design. There is no single correct structure — the right approach depends on how the organization manages access. The following are examples of how templates can be scoped. Most environments use a combination of several.

By job function

A template built around a role that bundles everything that function requires. A Sales Representative template covering HubSpot, Microsoft 365, and Slack means 1 assignment provisions a new hire across all 3 applications immediately.

By application

A template scoped to a single integration and a specific permission tier. A Slack Corporate template assigns Slack membership to any User who needs it, independent of their job role.

By permission tier

A template that grants a defined level of access within an application. A HubSpot Admin template and a HubSpot Read-Only template can be assigned to different Users in the same department based on what they actually need.

By department

A template covering all the tools a department uses at the appropriate permission levels, assigned to everyone in that group regardless of their specific title.

Combined

A User can hold more than 1 Role Template simultaneously. Whether they do depends on how the template structure is designed — a comprehensive job function template may cover everything a User needs on its own, while a mixed approach may result in Users holding several templates at once. Either is valid. Design for whatever produces the cleanest, most maintainable result for the organization.

Design principles

Templates represent functions, not individuals

A Role Template should reflect a job function, department, or access pattern — not a single person. If a template can only ever apply to 1 User, it is likely scoped too narrowly. Design templates that can be assigned to any User who performs a given function.

Build from real detected permissions

The most reliable starting point for a new template is an existing User's detected permissions. Find a User who represents the function well — someone whose current access reflects what that role should hold — and use their detected permissions as the baseline. This reduces the risk of building a template that omits access the function actually requires. In the platform, this can be done directly using the Create Template from User option. See Role Template Management for steps.

Overlap should be intentional

A User can hold multiple Role Templates simultaneously. However, overlapping templates should not conflict. If 2 templates assign different permission levels in the same application for the same User, the outcome is ambiguous. Design templates so that any combination a User might hold is deliberate and produces a predictable result.

Map HR roles to templates explicitly

For each HR role in the organization, document which Role Templates it maps to. Without an explicit mapping, access decisions become ad hoc — each onboarding, offboarding, or role change requires judgment instead of a lookup.

The role matrix

The role matrix is the planning document that connects HR roles to Role Templates and Role Templates to permissions. It is built in 3 layers, each answering a distinct question. Together they form the complete design that Role Templates in Tello IAM are built from.

Layer 1: HR roles to systems

The first layer establishes scope. For every HR role in the organization, identify which applications that role requires access to. This is a joint exercise between HR and IT that confirms every role is accounted for before any permission detail is defined.

Layer 2: Per-application permissions

For each application identified in layer 1, a separate worksheet documents exactly what each HR role requires within that system. Being in an application and having the right access within it are different things — a Sales Manager and a Sales Intern may both be in HubSpot, but they hold different permission levels. One worksheet per application captures that distinction.

The following is an example for HubSpot:

Build one worksheet per application. When all per-application worksheets are complete, every HR role has a fully documented permission set across every system it touches.

Layer 3: HR roles to Tello Role Templates

The final layer maps each HR role to the Role Template that will be assigned in Tello IAM. The recommended approach is a direct role-to-role mapping — each HR role receives one dedicated Role Template with a matching name. A Sales Manager HR role maps to a Role Template named Sales Manager, built from the permissions documented in layers 1 and 2. Anyone looking at a User's assigned template immediately knows what that person is and what access they should have.

Note: The role-to-role approach is the recommended starting point for most organizations. Tello IAM also supports other structures — application-specific templates, permission-tier templates, or combinations of both — which would produce a different layer 3. The right design depends on the organization.

Maintaining the matrix

Once the matrix is complete, access management becomes a lookup rather than a decision. A new hire joins as a Sales Representative — the Administrator finds the row, assigns the template, and provisioning is complete. A role changes — the Administrator updates the mapping and Tello IAM reflects it.

When HR introduces a new role, the Administrator works through all 3 layers to determine what the role requires. If existing templates cover it, adding the row is all that is needed. If the new role has requirements no existing template addresses, IT and HR work together to define the permissions, update the matrix, and build the new template from that agreed-upon design.

The matrix should be treated as a living document. As the organization grows and the application landscape changes, the matrix is the reference that keeps HR and IT aligned on what every role receives.

Related articles

• Role Template Management — create, edit, assign, and remove Role Templates in Tello IAM
• Getting Started Part 5: Planning your Role Template structure — guided walkthrough for first-time setup

Seasoft Security Solutions LLC | TelloIAM