Board personas describe the main ways people work with Board.
A persona is different from a license or a permission. The persona describes the user's responsibilities. The license defines the maximum functionality available to the user. Roles and other security settings determine what the user can actually access.
The primary Board user personas are Administrator, Developer, Planner/end user, and End user and Viewer.
Board personas
Use personas to identify the type of Board experience and documentation that is relevant to a user.
For example:
Administrators manage users, subscriptions, and the Platform and its access controls.
Developers build and maintain Board applications and Data Models and create Capsules in Design Mode.
Planners/end users use applications in Play Mode to plan and analyze information, executing actions without guidance, especially data entry, depending on the permissions defined for them.
Planners can be referenced as end users in the knowledge base since they have many of the same capabilities. Everything written for Planners and end users is subject to the user’s permissions and restrictions.
End users consume and analyze information, perform analysis, and execute guided actions such as Selections, data entry or input validation, depending on the permissions defined for them.
End users often have the same capabilities as a Planner but have a different persona because of their different use cases. Everything written for Planners and end users is subject to the user’s permissions and restrictions.
Viewers are an unofficial persona that lives under the Planner/End User persona that have read-only access to Board applications and use Play Mode exclusively to view reports, dashboards, and data without the ability to modify content or perform data entry. This is the purpose of a Lite license with further restrictions, but can also be attained by configuring a Role, Data Model Security, and disabling certain permissions like Data Entry with other licenses.
Viewers are not mentioned in the Knowledge base as a persona because the content is written to serve higher license personas. However, it is a possible persona.
A user's persona does not automatically grant access to these functions.
Administrator
An Administrator manages Platform-level settings, users, and security in the Administration section. Administrator access depends on the user’s license, Role, and administrative authorization. A user may have a Developer license without having access to every administrative function.
Typical Administrator tasks include:
managing Roles and Application Profiles;
managing security settings;
monitoring Platform activity;
managing other Platform configuration; and
performing user and license administration where the relevant Subscription Hub permissions are available.
Access to System Administration requires a Developer license and the required administrative authorization. Read more about the Administrative requirements.
An Administrator can also perform Developer or Planner tasks when the user's license and permissions allow them.
Developer
A Developer creates and maintains Board content.
Typical Developer tasks include:
creating and modifying Capsules and Screens;
configuring Objects and Layouts;
creating and modifying Procedures;
configuring application behavior; and
designing Data Models when the assigned license and Data Model Security permissions allow it.
A Developer license provides access to Data Model design and Capsule development.
A Power User license supports Capsule development but does not provide access to Data Model design.
Permissions can still restrict individual development features. For example, an Application Profile can deny access to the Layout Editor or Procedure editing.
Planner/end user
A Planner or end user primarily works with existing Board applications in Play Mode.
Planner and end user are different personas, but the knowledge base sometimes uses these terms interchangeably because their Play Mode activities overlap.
They are typically associated with different licenses: Planners with a Power User license, and end users with a User, User 15, or Lite license. This distinction is important when applying knowledge base information to a specific user. Actual access depends on the assigned license, permissions, and security configuration.
Actual access depends on the assigned license, permissions, and application configuration.
Typical Planner or end user tasks include:
opening and navigating Capsules
viewing and analyzing data
interacting with Objects
applying Selections
drilling into data
entering or changing data when Data Entry is available
Not available for Lite licenses. Lite licenses are considered Viewers.
running permitted Procedures.
An End user commonly uses a User and a User 15 license, and a Viewer typically has a Lite license, depending on the required functionality. Although, any license can be restricted enough to be considered only a Viewer.
A Planner can also be referenced as an end user but has a Power User license and supports Capsule development in Play and Design Mode, although, does not provide access to Data Model design.
A Lite license does not support Data Entry. A User or User 15 license can support Data Entry, but permissions and application configuration can still prevent it.
How personas, licenses, and permissions work together
Think of Board access as a sequence of controls.
First, the persona describes what the person needs to do.
The license then determines the maximum functionality Board can provide to that user.
Security and application settings can further reduce that access:
Role and Application Profile. Determine Platform access and which features are available.
Folder security. Determines which Capsule folders and Capsules the user can access.
Data Model Security. Determines the user's access to Data Models, Cubes, Entities, and data.
Security selections. Determine which parts of the available data the user can see.
Capsule, Screen, Object, and Layout configuration. Determines which interactions the application exposes.
What are these functions used for?
These controls do not normally increase the functionality provided by a license. They restrict the functionality that is otherwise available.
For example, assigning a User license does not guarantee Data Entry. Data Model Security can make a Cube read-only, and application configuration can prevent Data Entry on a particular Layout. Similarly, access to a Platform does not guarantee access to every Capsule. Folder security can prevent a user from opening a specific Capsule.
Requirements and limitations
The same persona can have different access in different Board environments or Platforms.
A Developer can have restricted access to a Data Model because of the assigned Role or Data Model Security profile.
A Planner can have a license that supports Data Entry but still have read-only access to specific Cubes.
A Planner can also be prevented from opening the Selection editor through an Application Profile or Screen configuration while still being able to interact with permitted Selector or Pager Objects.
For this reason, identify a user's access by checking the combination of license, Role, Application Profile, Folder security, Data Model Security, and application configuration rather than by persona alone.