Difficulty: expert
Content
Learning Objectives
After reading this article, you’ll be able to:
Understand Roles/Profiles set-up in Workplace
Select relevant roles per Workplace user
Create environment specific roles as per your needs
Roles and Profiles can be used to differentiate users, their rights and options in Workplace. If a user has multiple roles assigned to him/her, the overall scope of the user will be the sum total/union of all individual roles.
How to access:
Go to Workplace back-end https://studio.cobundu.com/
Login with your credentials
Select Roles & Profiles
Standard Roles
Every Workplace user is created with Default role. Either manually or through excel upload, any other role can immediately be assigned to a user.
“Default” role
The default role has a set of default permissions. Admins can manage the permissions of this default role.
It's not possible to remove this role
Following permissions are configured for Default role | Feature in GO |
---|---|
livedata.view | Live Data > View Room details |
reservations.view | Live Data > Create a reservation |
reservations.view | My Reservations |
replay.view | Replay |
reports.view | Dashboards |
kiosk.view | Kiosk mode |
“Admin” role is needed to access Studio (will only give access to current environment) and DeviceControl (for KioskApp and Workplace App)
! With great power comes great responsibility: make sure the Admin-user is aware of the Studio basics. Having access to Studio means being able to configure general Settings, Sensor Devices, User Management, Floor plan configuration etc => a basic training in Studio is needed before access can be given.
“Developer" role is typically assigned to users who have the rights to view/consume/integrate Workplace APIs. These users might be external developers who work on integrating Workplace with their systems, and should not have access to Workplace touchpoints.
On Workplace Web (GO), users with only developer role are automatically redirected to the API documentation upon login and cannot use any other front-end features.
On Workplace App, an alert will be shown and the user will not be allowed to continue.
Environment Specific Roles
Depending on the needs in your environment, other roles can be added to the environment (select "Add New"), for example access to dashboards on Workplace Web (GO) can be restricted for a specific role.
Role based reservation scope definition
Create a Workplace Role which restricts the user to see only a limited scope of locations, and to be able to make reservations only in those locations.
Step 1: Role definition
Add new role of Type "Reservation Restriction", and describe the reservation scope of a user by using any of the following 3 parameters:
location type
location scope
zone scope
Location Type - Each role can be defined for either only rooms, only workplaces, or both. | ||
Location tree with check boxes | Locations scope (buildings) - The locations in which the user is allowed to book a room or desk. | |
Zones scope - Rooms and workplaces can be linked to zones in Workplace under the Location Grouping settings. When a set of zones are enabled in a role, the user can only book rooms/workplaces linked to that zone. |
Step 2: Role assignment
Workplace users are assigned a default role. When users are assigned with another role ABC, this role specific permissions shall be applicable to the users along with ‘Default’ role permissions.
An administrator can assign one or more roles to a user. If a user has multiple roles assigned to him/her, the overall reservation scope of the user will be the sum total/union of all individual roles. See Users & Groups for more information on user creation.
When a Reservation Restricted Role is assigned, the user can only book rooms/workplaces described within the role on Workplace touch points. Reservation requests for other locations will be blocked by Workplace.
The restrictions only apply for bookings made via Workplace, and not for requests originating in the underlying IWMS from other sources (from Outlook through Exchange or IWMS web portal).
Also the other way around: IWMS restrictions will always be respected as it’s the underlying IWMS which owns the reservation data.
Settings in IWMS | Settings in Workplace | Result in IWMS | Result in Workplace | |
---|---|---|---|---|
No restriction / Allowed to book room X | No restriction / Allowed to book room X | -> | Allowed to book room X | Allowed to book room X |
No restriction / Allowed to book room X | Restriction set on room X | -> | Allowed to book room X | Not allowed to book room X |
Restriction set on room X | No restriction / Allowed to book room X | -> | Not allowed to book room X | Not allowed to book room X |
If a user is trying to book a resource that is outside of his/her reservation scope, an error message is shown
Search