Skip to Main Content

The Rich Role-Based Access Control (Rich Roles) feature enhances traditional role-based access control systems by incorporating detailed, structured user profiles into the system. This feature solves the critical business problem of generic and impersonal user experiences in B2B technology platforms, providing deeper personalization and relevance to each user interaction.

Traditional RBAC typically limits itself to granting permissions based on simplistic role categorizations such as Administrator or User. However, Rich Roles extends this model significantly, capturing comprehensive details about a user’s professional background, career progression, skills, technical competence, and job-specific responsibilities. These details enable highly contextual interactions and personalized experiences, particularly through interactions with Large Language Models (LLMs).

Users experience this feature implicitly. They receive tailored outputs, guidance, and content based on their detailed persona, leading to enhanced engagement, improved productivity, and a sense of system intelligence and awareness. For instance, a seasoned manager with extensive technical experience would encounter fewer basic instructions and more strategic insights, whereas an entry-level analyst would benefit from guided workflows and detailed explanations.

The management of Rich User Personas is reserved exclusively for System Administrators, who control the global definitions and feature permission mappings of these roles.   Users are assigned their respective personas through an automated onboarding and mapping process. This ensures immediate alignment and relevant content delivery from the user’s first interaction with the system.

Comparable features exist in advanced CRM or marketing automation platforms, where detailed psychographic and demographic profiles guide personalization. Rich Roles expands beyond marketing scenarios, embedding deep personalization into every system interaction. This allows the SaaS platform to intelligently adapt its communication and recommendations, ensuring relevance and precision aligned with each user’s professional reality.

Rich Roles are application-specific roles that are highly configurable and system specific. These roles can only be modified by System Administrators, ensuring a controlled environment. All system roles, including Customer Support (CS) and Customer Admin, can view these roles. The permissions for each role are integrated with the Feature Registry concept and can be tailored specifically for each Rich Role.

Rich Roles are system wide concept and are not specific to a given Customer. The Manager and Standard User roles below are provided as examples of the most common types of Rich Roles we’ll see but the exact set of Rich Roles will be highly system dependent.

Each Baseplate system most have at least one rich role and one role in the system carries a “default” role flag. The first user in a customer to register is created as the Customer Administrator for that Customer. Thereafter all new users that register are automatically assigned to the default role. Noting that the Customer Administrator for that Customer can then come in later and update that user to push them into a different role.

Manager

Managers have access to information about their direct reports, such as profiles, activities, and performance reports. They can monitor their team’s progress, access relevant data, and communicate with team members within the platform. For example, a Manager might review a team member’s progress on a project, share resources, or provide feedback. They can also monitor project status and key metrics.

Note that the Manager and Standard User roles are going to have the most application specific functionality developed for them while the other roles are relatively standard across applications in terms of their scope of access and features that they can view in the application.  Accordingly we’d expect more functionality would be defined for these two roles in the applications built on the stock app with relatively limited “standard” functionality built in the stock application itself.

Example Manager User Stories

Team and User Oversight

Communication and Collaboration

Standard User

The Standard User can create and update their profile, access data and information relevant to their tasks, and collaborate with team members. They can use the platform’s features and tools to complete their work, receive notifications and updates, and access help and support resources. For example, a Standard User might update their profile, collaborate with team members on a project, or submit a support ticket. They can also provide feedback and suggestions to improve the platform.

Example Standard User Stories

Profile and Settings Management

Collaboration and Communication

Support and Assistance

The above are a basic, starting model managing user permissions across all applications by role.   These would be created so they can readily be extended on a per app basis. 

Role Access and User Stories

System Administrator

System Administrators manage the global set of Rich Roles, overseeing creation, modification, and updates.  They can create, update, or remove roles at a global level—specifying the valid education levels, typical titles, responsibilities, skills, and other attributes. They also oversee the Automated User and Role Mapping process, ensuring that new users are assigned appropriate personas. While they are not necessarily the ones who directly benefit from the persona-based content (they’re typically in a back-end, system oversight role), they must guarantee that the system’s library of roles remains accurate, compliant with organizational policies, and up-to-date with evolving user segments.

User Stories

  1. As a System Administrator, I want to create new roles so users have relevant interactions immediately after onboarding.
  2. As a System Administrator, I need to modify the fields of a specific role to reflect changes in typical industry practices.
  3. As a System Administrator, I want to remove an outdated persona that’s no longer relevant to our user base, ensuring the system’s persona library remains clean and current.  As part of this process I need to be able to assign all current users in that persona to a new one.
  4. As a System Administrator, I want to refine the LLM queries that assigns roles to new users, improving our overall match rates and user satisfaction.
  5. As a System Administrator, I want to view a report that shows how many users fall under each Rich Role, helping me identify whether certain personas are overused or underutilized.

Customer Success

Customer Success representatives access role information to provide context-aware user support and troubleshoot user-specific issues effectively.  Customer Success representatives do not have the permission to create or modify Rich Roles at a global level, but they benefit immensely from seeing which role a user is assigned to. By understanding a user’s background, skill level, and pain points, Customer Success can deliver more targeted support. They can also verify that a user has been correctly assigned to a role and, if not, move the user to a correct role for them.  During onboarding calls or training sessions, having visibility into a user’s persona can inform the tone of communication, the examples given, and the recommended resources.

User Stories

  1. As a Customer Success rep, I want to quickly see which persona is assigned to a user so I can tailor my support approach to their background and experience level.
  2. As a Customer Success rep, I might suspect a user was misassigned to a ‘Tech Expert’ persona when they’re actually a ‘Cloud Expert,’ and I need to be able to reassign them.
  3. As a Customer Success rep, I want to see if certain personas are struggling with feature adoption, so I can proactively design targeted interventions or trainings.
  4. As a Customer Success rep, I want access to historical role assignments to troubleshoot discrepancies or user issues.

Customer Administrator

Customer Administrators view and manage role assignments within their Customer, ensuring accuracy and relevance for their users.  They cannot create new Rich Roles but can view which roles are assigned to their users and assign roles to different personas.  They have the same feature set as a Customer Success rep just specific to a given customer.

User Stories

  1. As a Customer Admin, I want to view role assignments to verify automated mappings.
  2. As a Customer Admin, I want to be able to change role assignment for users in my organization.
    1. Note that Customer Admins can only assign roles for Customer Administrator and below.   The System Administrator and Customer Success are reserved system roles and cannot be assigned by Customer Admins.

Manager and Standard User

Managers and Standard Users experience Rich Roles natively in the system and cannot modify or change their assigned roles.

Pages and Screens

Rich Roles Management Page (System Administrator Only)

This screen allows System Administrators to create, edit, and manage Rich Roles roles. Admins access this from the global settings dashboard.  Each role appears as a distinct entry with attributes such as Education, Titles, Experience range, Managerial status, Skills, Pain Points, Goals, and more. The page enables administrators to add new roles, edit existing ones, or retire obsolete roles. Quick filtering options let them search by education level, managerial status, or any custom fields that might have been added.

When a System Administrator selects a role entry, a detailed form appears, displaying all relevant attributes. This form might allow multi-value fields (e.g., a list of possible job titles or synonyms), textual paragraphs for responsibilities, bullet lists for goals, and radio buttons for managerial status. Validation ensures that mandatory fields like Education and Experience range are not left empty, maintaining consistency across the library. Changes typically require a confirmation step (e.g., “Save Changes” or “Cancel”), so administrators can safely experiment without inadvertently disrupting live user assignments.

Upon completion of the background for a given role the System Administrator is provided a feature list of the application that allows them to grant access to the feature and perform any secondary level configuration for access to that feature (example view / edit permissions).   In the Stock SaaS Application we can provide a basic model for application features that can be accessed with implementing apps extending this model.

The page includes an audit log or version history to track modifications. Because these roles can drive a wide array of LLM-based and user-experience customizations, it’s essential to maintain transparency around who changed what and when. This helps organizations remain compliant with internal governance policies and fosters confidence that role definitions are stable and well-managed.

Automated Role Assignment Configuration Page

System Administrators can configure how the system automatically assigns roles to new users. This page displays the current LLM query information used to assign a user into one of the list of provided roles.  The stock content for this is provided in the Automated User and Role Mapping section of this document.  The goal of exposing this in the UI is simply to provide Administrators a view into how the query for assignment works. 

Role Verification and Insights Dashboard

Both System Administrators and Customer Administrators can use this dashboard to gain a high-level view of role distribution across the platform or within a customer. It would provide a basic list of all the system roles that can be assigned (Customer Administrator and “below”) and the count of users assigned to each role as well as the percentage of system assignments going into each.   The same screen is provided at the Customer level with the data restricted to that customer.  

This screen should provide a breakout of feature access by Rich Role allowing us to see what features certain classes of users are using (and which they are not).  By examining these insights, administrators can identify possible misalignments—such as large numbers of users in an “Executive-level” role who rarely use the advanced collaboration features intended for that group.  Over time this dashboard can be extended to provide additional information relevant to the global role or customer specific roles such as user satisfaction or ticket frequency by role. For instance, if “Technical Experts” are lodging frequent tickets about missing advanced integrations, it signals a potential gap in the system’s offerings. Conversely, if “Basic Users” rarely file support tickets, it might indicate that the built-in tutorials are meeting their needs.

Finally, this screen supports strategic decision-making, such as whether to introduce a new role for an emerging user segment or whether to refine existing roles. Because it aggregates data from multiple customers (for System Administrators and Customer Success) or from multiple departments (for Customer Administrators), the dashboard becomes a central resource for role-driven insights. Export functionalities might allow easy sharing with leadership or other stakeholders.

Role Details Page

A page showing all the details for a specific role.   System Administrators and Customer Success will have access to view all data for the role.  Customer Administrators can view a list of non-sensitive attributes for the role —like job titles or years of experience.  This view is hidden from all other roles.

LLM Test Query By Role

One of the main consumer-facing benefits of Rich Roles is LLM-based personalization. The LLM Test Query By Role page allows System Administrators to “test” queries that define a given role as the target audience for the query.  The system takes the query, adds the role LLM attributes as the definition of the audience for the output and returns the results.  This screen is intended to work with edits to the roles to allow System Administrators to sanity check that the output for a given role is logical and correct.

Data Model

Rich Role Fields

The following fields are the “rich” fields we seek to capture for each role in addition to the basic system bookkeeping fields that are needed for each role (such as what features they can access, what level of access they have to that feature, etc.)

Rich User Role Table

An example table implementing the Rich Roles approach

NameData TypeDescriptionNotes
role IDintPrimary key for the role ID tableAutogenerated
industry IDintOptional.  Links to the ID for a specific industry indicating that this user role is specific to users from a given industryForeign key for the customer object.  Associates this role with a given customer
NameString (255)Name of this roleFormatted with {industry} + {leader title}
Education LevelMultiselect optionHighest level of education attained (e.g., Bachelor’s, Master’s)High School Diploma or EquivalentSome College or Associate’s DegreeBachelor’s DegreeMaster’s DegreeDoctoral Degree (Ph.D.)Postdoctoral TrainingVocational or Technical TrainingOther (please specify)
TitlesArrayList of titles and title variations for this roleLLM prompt – Please provide as many sample titles for this roles as possible
Experience LevelIntegerYears of experience in their field or roleEntry-level: 0-2 yearsEarly career: 2-5 yearsMid-level: 5-10 yearsSenior-level: 10-15 yearsExecutive-level: 15-20 yearsVeteran: 20+ years
ResponsibilitiesStringCouple of paragraphs describing the role of the person 
SkillsHTMLFormatted text description of the skills this person has 
Pain PointsHTMLChallenges or problems faced in current job.   This is not specific to our product or service and is general to their job as a whole. Formatted text with a bullet list or other description of their goals 
GoalsHTMLWhat they are trying to achieve in their job.   This is also not specific to our product or service and is general to their job as a whole. Formatted text with a bullet list or other description of their goals 
Solution Relevant Pain PointsHTMLSpecific tasks or areas where they struggle that relate to our product or service.   This could be a subset of the general Pain Points or a more nuanced combination of the business problems we solve in the context of their job 
Solution Relevant GoalsHTMLSpecific things they are trying to get done that relate to our product or service. 
Current SolutionsHTMLTools, software, or processes currently used to accomplish goals currently that relate to our product or service 
Unsatisfied WithHTMLAspects of current solutions that are unsatisfactory w/r/t what they are trying to accomplish 
Ideal OutcomeHTMLDesired outcome or results from solving their Solution Relevant Pain Points and delivering against their Solution Relevant Goals 
Digital SavvinessSelectTheir level of comfort with technology (e.g., beginner, intermediate, advanced)Digital Novice: Has little to no experience with computers or digital technology.Basic User: Can perform simple tasks like browsing the internet, sending emails, and using basic software applications.Digital Citizen: Has a good understanding of basic computer skills, online safety, and digital etiquette.Intermediate User: Can use more advanced software applications, troubleshoot basic technical issues, and understand basic online security measures.Tech-Savvy: Has a strong understanding of computer systems, software applications, and online platforms, and can adapt quickly to new technologies.Power User: Has advanced technical skills, can customize software applications, and can troubleshoot complex technical issues.Digital Specialist: Has expert-level knowledge in a specific area of digital technology, such as web development, data analysis, or cybersecurity.Tech Expert: Has a broad and deep understanding of digital technologies, including hardware, software, networking, and cybersecurity.Innovator: Stays ahead of the curve with the latest digital trends and technologies, and can apply this knowledge to create innovative solutions.Digital Thought Leader: Is recognized as an expert in digital technology and is sought out for advice, guidance, and strategic direction.
Decider / Influencer BooleanAre they the person that controls the budget for the solution we are selling? (TRUE)If not we assume they are an influencer in the buying process 
LLM Audience PromptStringThis is a concatenation of all the values in the final column of the table returned by the LLM that we can later use to define the audience for content 

LLM Creation Notes

You are a product manager for a B2B Technology Company.  Create a user role for a [name] for use as part of product definition document.

As you write keep in mind the following description of our solution: 

[Markdown text of this document’s overview section]

For the buyer role provide me the following fields and no other commentary:

Education – Highest level of education attained selected from the list of options: High School Diploma or Equivalent, Some College or Associate’s Degree, Bachelor’s Degree, Master’s Degree, Doctoral Degree (Ph.D.), Postdoctoral Training, Vocational or Technical Training.  Single selection only.

Titles – List of titles and title variations for this role.  List as many as possible.

Experience – Years of experience in their field or role selected from the following list: Entry-level: 0-2 years, Early career: 2-5 years, Mid-level: 5-10 years, Senior-level: 10-15 years, Executive-level: 15-20 years, Veteran: 20+ years

Responsibilities – A few paragraphs describing the role of the person

Manager? – Yes / No answer stating if this oversees the work of other people

Department – A list of common names for the team or organizational department this person works in

Skills – Formatted text description of the skills this person has

Pains – Formatted text description of the challenges or problems faced in current job or role this person has.   This is not specific to our product or service and is general to their job as a whole. Formatted text with a bullet list or other description of their goals.

Goals – What they are trying to achieve in their job.   This is also not specific to our product or service and is general to their job as a whole. Formatted text with a bullet list or other description of their goals

Relevant Pain – Specific tasks or areas where they struggle that relate to our product or service.   This could be a subset of the general Pain Points or a more nuanced combination of the business problems we solve in the context of their job

Relevant Goals – Specific things they are trying to get done that relate to our product or service.  In addition to role specific goals, include in this list ideas on how the solution may help them advance their career or their internal reputation in the company.

Current Solutions – Tools, software, or processes currently used to accomplish goals currently that relate to our product or service.  When possible link the name of the solution to a landing page describing the solution.

Switching Costs – A description of the costs associated with switching from their current solution to ours

Unsatisfied With – Aspects of current solutions that are unsatisfactory w/r/t what they are trying to accomplish

Ideal Outcome – Desired outcome or results from solving their Solution Relevant Pain Points and delivering against their Solution Relevant Goals

Articles of Interest – List of up to twenty topics for long form articles that this person might be interested in engaging with.

Digital Savviness – Their level of comfort with technology selected from the following list: Digital Novice: Has little to no experience with computers or digital technology; Basic User: Can perform simple tasks like browsing the internet, sending emails, and using basic software applications; Digital Citizen: Has a good understanding of basic computer skills, online safety, and digital etiquette; Intermediate User: Can use more advanced software applications, troubleshoot basic technical issues, and understand basic online security measures; Tech-Savvy: Has a strong understanding of computer systems, software applications, and online platforms, and can adapt quickly to new technologies; Power User: Has advanced technical skills, can customize software applications, and can troubleshoot complex technical issues; Digital Specialist: Has expert-level knowledge in a specific area of digital technology, such as web development, data analysis, or cybersecurity; Tech Expert: Has a broad and deep understanding of digital technologies, including hardware, software, networking, and cybersecurity; Innovator: Stays ahead of the curve with the latest digital trends and technologies, and can apply this knowledge to create innovative solutions; Digital Thought Leader: Is recognized as an expert in digital technology and is sought out for advice, guidance, and strategic direction.

Decider: Yes / No statement if this controls the budget for the solution we are selling?  If No we will assume they are an influencer in the buying process

Format the results as a table.  When you pick an option from a list include the description along with the option.   Include a column in the table that provides text that restates the Value of the field as a fact.

Not that the last column in the table is the set of instructions to be placed in the LLM Audience Prompt field

Automated User and Role Mapping

Based on the user’s work e-mail and a search of the Organization Graph we’ll automatically match the users to a real, known person and automatically assign them to one of the systems Rich User roles.

LLM Prompt:

You are an AI researcher.  I am trying to assign a user to a specific user role in my application.   This is the following functionality of the application:

[Markdown text of this document’s overview section]

Here’s what I know about the user:

[Rich output of the People entry for the user]

Given what you know about the user please classify them into one of the following user roles

#[role 1 Name]

[role 1 LLM Audience Prompt]

#[role 2 Name]

[role 2 LLM Audience Prompt]

Etc.

Return me only the name of the selected role and no other information.

The LLM may very well give you a lot of other information back but you should be able to quickly search the text by role name and find the matching role name.  If we don’t find a match prompt the user with role options.