Getting Started Part 5: Planning Your Role Template Structure

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

About:  This article helps the Administrator plan a role template structure before building in Tello IAM. It covers how role templates map to connected integrations, how assigning a template overrides directly detected permissions, and how to design a structure that will scale as integrations are added. 

Stop before configuring

This article contains no platform steps. Before the Administrator builds a single Role Template, the structure of the entire template library needs to be designed on paper. The decisions made here determine how cleanly Tello IAM manages access going forward. A well-designed Role Template structure is simple to maintain and easy to audit. A poorly designed one creates ambiguity, overlapping permissions, and provisioning errors that compound over time.

The deliverable of this article is a completed Role Template matrix — a mapping document that connects HR roles to Role Templates, and Role Templates to permissions. That matrix becomes the build plan for Part 6 and the ongoing reference for access decisions going forward.

What changes when Tello takes over permission management

Before Role Templates are assigned, Tello IAM is observing access — detecting and displaying what each User holds in connected applications, but not 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. The Role Template defines exactly what access the User should have, and Tello enforces it.

Important: When a Role Template is assigned to a User, it 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 Role Template is removed. The Administrator must account for this before assigning templates.

This override behavior is what makes Role Template design consequential. A template that is incomplete or incorrectly scoped will remove access a User needs. Design templates to be complete representations of what a User in a given function should hold.

How HR and IT fit together

HR and IT often use different language to describe the same people. HR defines roles in their own system — Sales Manager, Sales Rep, Sales Intern — using terminology that reflects the organization's structure. IT configures access in Tello IAM using Role Templates that reflect permission patterns. These 2 systems do not always mirror each other directly, and they do not need to.

The Role Template matrix is the document that connects them. It maps each HR role to the Role Template or Templates that cover it. This gives both teams a shared reference:

• HR knows what access each of their roles receives
• IT knows which templates to assign when a new hire joins or a role changes

When HR introduces a new role, the Administrator looks at the matrix and determines whether existing templates cover it. If they do, assignment is straightforward. If the new role has requirements that no existing template addresses, that is when IT and HR need to work together — defining the permissions the role requires, updating the matrix, and building the new template from that agreed-upon design.

This HR/IT collaboration should happen before any templates are built in Tello IAM. The matrix is a joint deliverable.

Role Template design approaches

Role Templates are flexible by design. There is no single correct way to structure them — the right approach depends on how the organization manages access. The following are examples of how templates can be designed. 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 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.

Role Template design principles

Apply the following principles when designing the template structure:

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 approach reduces the risk of building a template that omits access the function actually requires.

In Part 6, this can be done directly in the platform. If a User already has exactly the access a template should represent, their detected permissions can be copied into a new template in a single step.

Overlap should be intentional

A User can hold multiple Role Templates simultaneously. This is by design — a User might hold a role-based template for their job function and an application-based template for a specific tool. 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 combinations are deliberate and produce a predictable result.

Map HR roles to templates explicitly

For each HR role in the organization, document which Role Templates it maps to. This becomes the assignment guide used in Part 6 and the reference for every onboarding, offboarding, and role change that follows. If a mapping does not exist for a role, access decisions become ad hoc.

The matrix

The matrix is not a single document. It is a set of connected worksheets that, taken together, answer 3 questions in sequence: which systems does each role touch, what permissions does each role hold within each of those systems, and which Role Templates in Tello does each role receive. Each layer feeds directly into the next.

Layer 1: HR roles to systems

The first worksheet establishes scope. For every HR role in the organization, mark which applications that role requires access to at all. This is the coverage map — a joint exercise between HR and IT that confirms every role is accounted for before any permission detail is discussed.

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

The following is an example for HubSpot:

Build 1 worksheet per application. When all per-application worksheets are complete, every role has a fully documented permission set across every system it touches. That documentation is what the Role Templates in Tello are built from.

Layer 3: HR roles to Tello Role Templates

The final worksheet is the Tello IAM master list. It maps each HR role to the Role Template that will be assigned in Tello. The recommended approach is a direct role-to-role mapping — the Sales Manager HR role receives a Role Template in Tello called Sales Manager, built precisely from the permissions documented in layers 1 and 2. The name matches intentionally. Anyone looking at a User's assigned template immediately knows what that person is and what they should have.

Repeat this process for every HR role in the organization. When the last template is built, the matrix and Tello match. HR has a living document that explains what every role receives. IT has a platform that enforces it.

Note: The example above demonstrates a role-to-role approach, where each HR role maps to 1 dedicated Role Template. This is the recommended starting point for most organizations. Tello IAM also supports other approaches — application-specific templates, permission-tier templates, or combinations of both — which would produce a different structure in this layer. The right design depends on the organization.

How this scales

Once the matrix is complete, access management becomes a lookup, not a decision. A new hire joins as a Sales Representative — the Administrator finds the row, assigns the template, and provisioning is done. A role changes — the Administrator updates the mapping and Tello reflects it. HR introduces a new role — the Administrator works through all 3 layers to determine what the role needs. If existing templates cover it, add the row. If they do not, IT and HR work together to define the permissions, update the matrix, and build the new template from that agreed-upon design.

Organizations that align on this mapping before they need it handle headcount changes, reorganizations, and onboarding at speed. Organizations that skip it make access decisions ad hoc — and those decisions accumulate into the exact kind of permission sprawl Tello IAM is designed to prevent.

Note: It is normal for the matrix to evolve during the build process in Part 6. The goal here is to have a working design before beginning configuration — not a perfect one. A documented starting point prevents ad hoc decisions during the build.

Next steps

When the matrix is complete and HR and IT have aligned on the role-to-template mappings, proceed to Part 6 — Configuring role templates to build the templates in Tello IAM.

This article is Part 5 of the Getting Started with Tello IAM series.

Next: Getting Started Part 6: Configuring Role Templates

Previous: Getting Started Part 4: Connecting additional integrations

Getting Started series

1. Platform Overview
2. Connecting your IDP and HR integrations
3. Verifying your user data
4. Connecting additional integrations
5. Planning your Role Template structure (current)
6. Configuring Role Templates
7. Configuring Teams
8. Monitoring access with Change History, Access Overview, and Reports
   
   
   

Seasoft Security Solutions LLC | TelloIAM