Administration • Security & PermissionsAdministrator Only

License
Administration.

Giving someone access to Presto is more than selecting a license type. Effective administration requires three connected decisions: choosing the right user license, defining how far that person can see and work through the organisational hierarchy, and deciding which modules, dashboards and features they are permitted to use.

Business leader managing team access and permissions in Presto PDCA
The administrator mindset

Access should match responsibility.

The objective of license administration is not to give every user the same experience. It is to give each person the right level of access for the work they are expected to perform while protecting information, reducing unnecessary complexity and keeping accountability clear.

A Presto license is really an access profile.

Think of each user as having three connected settings: their license type, their position and reach within the hierarchy, and their functional permissions. The combination of those settings determines their practical Presto experience.

Business leader working with a management team
Good access design starts with understanding the person's role, responsibility and operating context.
Presto's Three Access Control Layers

Three decisions shape every user's experience.

Treat these as three separate controls. A user's license type does not, by itself, determine everything they can see, everything they can work on, or every feature available to them.

01
Identity & operating role

License Type

Select the license that best reflects how the person will use Presto. This establishes the broad user profile and the type of interaction expected from that person.

Administrator questionWhat type of Presto user should this person be?
  • Administrator
  • Manager
  • User
  • Staff / Feeder
02
Organisational reach

Hierarchical Visibility & Workability

Define how far the user can move through the organisational hierarchy when using the Presto Dashboard - both what they are permitted to see and where they are permitted to work.

Administrator questionHow high through the organisation should this person be able to see and operate?
  • Dashboard visibility level
  • Dashboard workability level
  • Organisational hierarchy boundaries
03
Functional access

Module & Dashboard Permissions

Decide which Presto modules, dashboards and specific capabilities should be available to the user through the Permissions configuration panel.

Administrator questionWhat should this person actually be allowed to access and use?
  • Module access
  • Dashboard permissions
  • Feature-level configuration
KEY
Do not treat these controls as interchangeable.

A person can have an appropriate license type but still have the wrong hierarchical reach or unnecessary module access. Good administration means reviewing all three control layers together.

What access control looks like in Presto

One user can have different levels of reach and functionality.

The Permissions workspace makes these controls practical. Administrators can define organisational scope separately from the modules, dashboards and features made available to the user.

Visibility is not the same as workability

Seeing higher in the organisation does not automatically mean being able to work there.

Presto separates the level at which a user can actively operate from the level at which they may have wider read-only visibility. This allows administrators to support management oversight without unnecessarily extending editing or management rights.

Workability Scope

The highest organisational level where the user can actively work, update, manage and edit records.

Visibility Scope

A higher read-only level, limited to activities where the user is included in the RACI matrix.

Simple way to remember it: Workability = can do and edit. Visibility = can view where included in RACI.
The third control layer sits alongside these hierarchy settings.

The same Permissions workspace is also used to determine which common features, dashboards, filters, widgets and reports are available to the user. Hierarchical reach and functional permission therefore need to be considered together, but configured as separate decisions.

Presto PDCA permissions screen showing organisational workability and visibility configuration with common feature access
Live Presto example: organisational scope and common feature access within the Permissions workspace.
Layer 1 - License Type

Start with the user's operating profile.

License Type is the first decision because it establishes the broad relationship the person will have with Presto. The detailed configuration steps are covered next in the License Type Configuration job aid.

AdministratorFor users responsible for configuring, governing or administering elements of the Presto environment.
ManagerFor leaders who actively manage work, performance, teams and governance through Presto dashboards.
UserFor people who need normal Presto access to participate in work, projects and performance management.
Staff / FeederFor contributors who primarily provide task or KPI updates through Presto's push-email experience without normal dashboard access.
A simple administrator decision flow

Who are they? Where can they operate? What can they use?

Using the same three questions every time creates a repeatable access-management discipline and makes future license reviews much easier.

Decision 01

Who is this person?

Choose the appropriate license type based on the person's role and how they are expected to participate in Presto.

Decision 02

Where can they see and work?

Configure the person's hierarchical visibility and workability so their dashboard reach matches their organisational responsibility.

Decision 03

What can they access?

Assign the modules, dashboards and specific features required for their job - and avoid providing unnecessary access.

Administration is an active responsibility

Set access deliberately - then keep it current.

User responsibilities change. Teams move, managers take on broader remits and people leave roles. License administration should therefore be treated as an ongoing governance activity, not a one-time setup task.

Manager leading a business team meeting

Design access around accountability.

Start from what the person is accountable for, then configure the minimum access needed to perform that responsibility effectively.

Business leaders reviewing organisational performance together

Review access as responsibilities change.

Revisit user configurations when roles, reporting lines, team ownership or governance responsibilities change.

You now have the administration model.

The learning path now follows the same sequence an administrator should use in practice: configure the License Type first, then Hierarchical Visibility & Workability, then Module & Dashboard Permissions. Password administration follows once the user's access profile has been configured.