User Permissions Guide

How to assign permissions, roles, and company/location access

Summary: Permissions define what a user can do in Vemcount. Roles are reusable permission sets. Company and location access define which data the user can see.

This guide explains how to assign permissions to a user in Vemcount and how permissions relate to roles and company/location access.

Path in Vemcount

Cogwheel icon → Users → Select user → Permissions & Access → Permissions

Ways to assign permissions

When creating a new user account and setting permissions individually
When creating a new user account and applying a predefined role
When editing an existing user account and changing permissions individually
When editing an existing user account and applying or updating a predefined role

Before you start

It is useful to distinguish between permissions, roles, and company/location access before configuring a user.

Element	Description
Permissions	Define what the user is allowed to do in Vemcount, for example managing setup, viewing dashboards, or using data-related functions.
Roles	Predefined permission sets that can be assigned instead of selecting each permission manually.
Company and location access	Define which companies, locations, or sub-locations the user is allowed to access.

Important: A user may have the correct permissions but still be unable to view data if access to the relevant company or location has not been assigned.

How to assign permissions to a user

Click the cogwheel icon and select Users.
Select an existing user account, or create a new user.
Complete the user details such as base company, username, email, full name, timezone, and language.
If you are creating a new user, click Save and go to permissions.
Open the Permissions section.
Assign the required permissions either individually or by applying a predefined role.
Go to Companies and assign the relevant company, location, or sub-location access.

Permission categories

Based on the current interface, permissions are grouped into categories such as:

Setup Management

Metrics

Dashboard

Tenant

Tracking

Data Manager

Services

Security

Each category contains more specific permissions. Depending on the area, permissions may use access levels such as Off, View, or Manage.

Roles vs. individual permissions

In many cases, it is recommended to assign a role instead of configuring permissions one by one. Roles help ensure that users with similar responsibilities receive the same level of access.

Use individual permissions when...	Use roles when...
the user needs a custom setup only a few permissions differ from a standard role	several users need the same access level you want a more consistent and scalable setup

Related access setup

After assigning permissions, you must also assign the user to the correct company or location. Without this, the user may be able to log in but still not see any relevant data.

Company level: access to all data in the assigned company
Single location: access only to one selected location
Location including sub-locations: access to a location hierarchy where applicable

Common examples of permissions

Permission	Typical effect
Footfall	Allows the user to report on footfall traffic and view shared footfall dashboards.
Weather	Allows the user to report on weather and include weather widgets in dashboards.
Maps	Gives access to Maps and traffic heatmaps.
Age and Gender	Gives access to Age and Gender reporting.
Events	Enables event visibility in the calendar and reporting.
Manage Events	Allows the user to add and edit events.
Promote to library	Allows dashboards to be shared to the library as templates.
Allow embedding	Allows dashboards or widgets to be embedded externally.
View only	Restricts the user to a view-only role.
Manage Users	Allows the user to create and manage users.
Share reports	Allows the user to share saved reports to roles.

Best practice

Use roles where possible to keep permission management consistent.
Always verify both permissions and company/location access.
Use individual permissions only when a user needs exceptions to a standard role.
Test the user account after setup if there is any doubt about access.