Skip to content
  • There are no suggestions because the search field is empty.

Accounts and users in HCP

Introduction

This guide explains the different types of accounts and users in Humly Control Panel (HCP), helping you understand how user management works and the distinction between HCP accounts and your booking system accounts.

Understanding the Two Account Systems

Humly Control Panel and your booking system use separate user databases.

This is a common source of confusion for new administrators. Here's what you need to know:

1. Booking System Accounts

  • Managed in your booking system (Microsoft 365, Google Workspace, Exchange, etc.)
  • Used for calendar integration, booking resources
  • Created and managed in your booking system's admin interface
  • Examples: Office 365 Admin Center, Google Workspace Admin, Exchange Admin

2. Humly Control Panel Accounts

  • Managed in Humly Control Panel
  • Used for accessing HCP administrative features
  • Created and managed in HCP Users section
  • Independent credentials from booking system

Key Point:

Even if a user has the same email address in both systems, the passwords are different.

For example:

These are two separate accounts with different purposes.

Service Account Explained

The Service Account is a special account that connects Humly Control Panel to your booking system.

What It Does

  • Enables HCP to read and write to your booking system calendars
  • Synchronizes bookings between HCP and your calendar system
  • Authenticates API requests to your booking system

Important Notes

  • Depending on the booking system you are using. The Service account credentials are configured in Settings > Global Settings > Booking System
  • If you change the service account password in your booking system, you must update it in HCP
  • Service account password change does NOT affect your HCP login password
  • Requires appropriate permissions in your booking system (see booking system preparation guides)

Example Scenario

  1. Your Exchange service account is: hcp-service@company.com
  2. You change the password in Exchange Admin
  3. You must update the password in HCP Settings > Global Settings
  4. Your HCP login credentials remain unchanged

User Types and Roles

Humly Control Panel supports multiple user types, each with different permission levels:

Global Admin (Admin)

Full administrative access to all features

  • Manage all users, resources, structures, and settings
  • Configure global settings, booking systems, integrations
  • Access all locations/buildings in the organization
  • Assign structures to Local Admins
  • Perform system backups and maintenance

Best Practice: Maintain at least 2-3 Global Admin accounts to prevent lockout if one admin forgets credentials.

Local Admin

Administrative access limited to specific locations

  • Manage resources within assigned structures only
  • View statistics for assigned locations
  • Configure resources and settings for their structures
  • Cannot access global system settings
  • Cannot manage Global Admins

Use Case: Building managers, floor coordinators, department admins

Structure Assignment: Global Admins assign which countries/cities/buildings/floors a Local Admin can manage.

Visitor Admin

Specialized role for visitor management

  • Manage visitor registrations and check-ins
  • Access visitor logs and reports
  • Can be assigned to specific structures
  • Cannot manage regular users or resources

Use Case: Reception staff, security personnel, front desk operators

Statistics User

Read-only access to reports and analytics

  • View statistics and reports for assigned structures
  • Export data for analysis
  • Cannot modify any settings or users
  • Cannot manage resources

Use Case: Management, analysts, finance teams needing usage data

User

Standard booking user

  • Make bookings for rooms, desks, parking spaces
  • Access Humly Reservations and Floor Plan
  • Manage their own bookings
  • Cannot access administrative features
  • Cannot create or modify resources

Use Case: All employees who need to book meeting rooms or desks

Guest

Limited access for users without booking system accounts

  • Can make bookings in Humly Reservation based on the assigned permissions
  • Email does not exist in connected booking system
  • Cannot be upgraded to other user types in some configurations
  • Useful for contractors, visitors, external users

Important: When creating a user whose email doesn't exist in your booking system (MS365, Google, Exchange), HCP will only allow the Guest user type.

Credentials Explained: PIN vs Password

Users in Humly have two types of credentials, each serving different purposes:

Password

Used for: Full authentication and system access

  • Logging into Humly Control Panel
  • Logging into Humly Reservations
  • Accessing integrated booking systems
  • Web-based and desktop application access

Format: Alphanumeric with special characters
Managed by: User can change in their profile, admins can reset
Security: Should follow organization's password policy

PIN (Personal Identification Number)

Used for: Quick verification and device authentication

  • Identifying yourself on Humly Room Displays
  • Making bookings from Interactive Floor Plan kiosks
  • Quick authentication on Humly booking devices
  • Touch-screen friendly authentication

Format: Numeric code (typically 4-6 digits)
Managed by: User can change in their profile, admins can reset
Security: Shorter than password but sufficient for device verification

Configuration: PIN length is configured globally in Settings > General > PIN Digits

PIN Use Cases

Your PIN is used for quick authentication on Humly devices without requiring your full password. Here are the scenarios where you'll use your PIN:

Humly Devices

  • Check in to your booked meetings
  • Create ad-hoc bookings directly on the display
  • Extend ongoing meetings
  • End meetings early
  • Cancel bookings

Interactive Floor Plan Kiosk

  • Book resources from the floor plan
  • Modify your bookings
  • Cancel your bookings

Benefit: Fast, convenient authentication without exposing passwords on shared devices.

Single Sign-On (SSO) Integration

If your organization uses SSO, HCP can integrate for centralized authentication.

How SSO Works with HCP

  1. User Authentication

    • Users click "Sign in with SSO"
    • Redirected to your organization's identity provider.
    • Enter corporate credentials
    • Redirected back to HCP, automatically logged in

  2. SSO User Management

    • SSO users can be synchronized from Azure AD groups
    • User types can be controlled by group membership
    • Password management happens in your identity provider
    • MFA (if configured) is handled by identity provider

  3. SSO User Indicators

    • SSO users show a gray "SSO" badge in the Users list
    • Password reset is disabled (managed via SSO)
    • User type may be restricted (controlled by SSO groups)

Multi-Factor Authentication (MFA)

MFA adds an extra layer of security beyond passwords.

How MFA Works

  1. User enters email and password (first factor)
  2. User provides second factor (authenticator app code, SMS, etc.)
  3. Both factors must be correct to log in

MFA in HCP

  • Users can enable MFA in their profile settings
  • MFA status shown in Users table (green checkmark ✓)
  • Admins can revoke MFA if user loses access to their device
  • Recommended for all Global Admins

MFA vs PIN

  • MFA: Security feature for login authentication
  • PIN: Convenience feature for device identification
  • They serve different purposes and can be used together

Structure Assignment Concept

Structures are the organizational hierarchy in HCP: Country > City > Building > Floor

Why Structure Assignment Matters

Global Admins:

  • Automatically have access to all structures
  • Can manage everything across all locations

Local Admins, Visitor Admins, Statistics Users:

  • Must be assigned specific structures
  • Can only manage/view their assigned locations
  • Cannot see or manage other structures

Assignment Hierarchy

When assigning structures to a Local Admin:

  • Assign Country → Admin manages all cities, buildings, floors in that country
  • Assign City → Admin manages all buildings and floors in that city
  • Assign Building → Admin manages all floors in that building
  • Assign Floor → Admin manages only that specific floor

Example

Scenario: Building manager for "Headquarters Building" in "Stockholm"

Assignment:

  • Country: Sweden
  • City: Stockholm
  • Building: Headquarters Building

Result: Admin can manage all floors in Headquarters Building, but not other buildings in Stockholm.

Best Practices

Account Management

  • Multiple Global Admins: Always have 2-3 Global Admin accounts to prevent lockout

  • Descriptive Usernames: Use corporate email addresses for easy identification

  • Consistent Naming: Use same email in HCP and booking system (easier to manage)

  • Regular Audits: Review user list quarterly, remove inactive users

  • Principle of Least Privilege: Assign minimum necessary user type

Security

  • Enable MFA: Require MFA for all Global Admins

  • Strong Passwords: Follow organizational password policies

  • PIN Security: Treat PINs as confidential, reset if compromised

  • SSO When Available: Use SSO for centralized security management

  • Regular Password Resets: Periodic password resets for high-security environments

User Types

  • Default to User: Most employees should be "User" type

  • Limited Local Admins: Only assign Local Admin to those who need it

  • Structure Assignment Review: Audit Local Admin structures quarterly

  • Guest for External: Use Guest type for contractors, visitors, non-employees

Common Misconceptions

"If I change my password in Office 365, it changes in HCP"

False. HCP and booking system use separate password databases. Change passwords in each system independently.

"PIN can be used to log into HCP"

False. PIN is only for device verification (Room Displays, kiosks). Use password for HCP login.

"Guest users can't make bookings"

False. Guest users can make bookings in HCP, they just don't have an account in the backend booking system.

"Local Admins can manage all resources"

False. Local Admins can only manage resources in their assigned structures.

"SSO users can reset password in HCP"

False. SSO user passwords are managed in your identity provider (Azure AD, ADFS), not HCP.

"Service account needs to be a real person"

False. Service account should be a dedicated system account (e.g., hcp-service@company.com), not a personal account.

Related Documentation