# Release notes Visit 4.19

# Overview

# Visit Connect

# Improved on-boarding experience

We have modified the on-boarding experience for iOS users - it is now lighter, easier to read and to action upon the suggested steps in the flow.

# Visit

# Accounts

To ensure the flexibility organisers need when giving their team access to Visit, we’ve made significant changes to Accounts. There are more options for different permissions, and permissions are grouped into roles. User accounts can be a member of one or more roles to assign the permissions.


  • Accounts are now an integral part of the menu Organisation > Accounts.
  • We have removed account types. All new accounts created will be Standard. Following the release, all former Administrator accounts will be converted to Standard, while keeping the same permissions.


All existing accounts will maintain their permissions following the release. No action will be needed to ensure they have the same access level.


  • We have extended the permissions list to better capture the different scenarios and needs when using Visit. View here the list of all permissions.
  • Permissions can be assigned 2 different modes: read-only (view information, no edit rights) and read/write (can add/change information too).


Account Management has been split into: Accounts and API

View Basic Intelligence and View Advanced Intelligence have been replaced with Intelligence.

Service Centre has been replaced with Visitor and Partner.

Set up Event has been replaced with Events.


  • We have created default roles with default associated permissions. Permissions for default roles can be amended based on needs. An account can have one or more roles assigned, however it will inherit the permissions of the most “powerful” role.

Example: If a user is assigned two roles, and one has, for example, a 'read only' permission to Shop, and the other role has 'read/write' permission to Shop, then that user will be granted the higher read/write permission.

View here details of the default roles.

  • We have added the option to edit these default roles and to create custom roles within an organisation. Custom roles and their set permissions can be used across all organisation and its events.


  • Activity log has been moved to Organisation > Accounts and renamed to Log.
  • When creating an account, you can decide to restrict its access to specific events.
  • A list of all accounts can be exported from Visit.
  • Accounts with no activity within the last 6 months will be automatically disabled.

# API keys

  • API is now part of the main Visit menu under Organisation.
  • To manage API keys, a user will need to have the API permission enabled.
  • An API key can be restricted to specific IP addresses. There is now a field which allows the API key managers to set location restrictions.
  • API keys are, from now on, only visible to people within the organisation they belong to (previously visible to Visit support team too).
  • API keys can now be exported from Organisation > API > Keys.

# Improvements

Country list - you can hide and translate countries now.

Formatting phone fields - Phone numbers are now formatted into a standardized way.

Activities - users can now download all on-site activity logs, directly from the Service Centre and also filter per location, partner, content or time.

Registration type rule - we have added a new rule which assigns users a specific registration type based on the session(s) they purchase. Users can add a minimum limit of a session which need to be purchase in order to link registrants to a specific registration type.

Licenses - an overview of all licenses issued with an event is now available in Event > Licenses.

Dynamic fields - we have renamed #badge_code# to #visitor_code# and #registration_key# to #contact_code#.

# Payments

Mollie is now part of our directly integrated payment service providers - https://www.mollie.com (opens new window)

# Security enhancements

Two-factor authentication

For a more secured access to Visit, we have enabled two-factor authentication (2FA), whereby a user is sent a code to their device as part of the login process. You can read what 2FA is here (opens new window).

  • 2FA can be set for each role. Any user who is a member of a role requiring 2FA will be required to enter an additional code to access Visit.
  • By default, only super user accounts will have 2FA enabled. For standard accounts this has to be manually added by the person managing Accounts, under each chosen role.
  • By default, when 2FA is enabled, a verification code is sent to the email address that the account is associated with. However, if desired, the code can also be sent to an authenticator app on a smartphone, sunch as Google Authenticator or Microsoft Authenticator. Alternatively, if a mobile number is provided, the code can be sent via SMS.
  • Users can opt to 'trust' their device and not need another authentication code for 7 days.
  • For those cases in which there is a phishing attack suspicion, we’ve added the option for the Accounts user to force all users in their organisation to change their password.


Accounts with no activity within the last 6 months will be automatically disabled.