Multisite
When to choose for multisite
Use multisite when you want to aggregate data and standardise processes over sites
Separate tenant per site | Separate tenant per BU | Single tenant for all BU’s and sites | |
|---|---|---|---|
Idea | When local sites have a lot of freedom and flexibility. | When you want to maintain flexibility on BU level and want to standardize sites within a BU. | When you want to standardize all sites. |
Impact | Each site can configure their own flows. More configuration work. | Configuration is shared over all sites within the business unit. Each change to configuration should be aligned within the change advisory board per business unit. | Configuration is shared over all sites in the company. Each change to configuration should be aligned within the change advisory board per site. |
When reporting is required over multiple sites, data must be centralised in BI-tool or manually. | When reporting is required over multiple BU’s, data should be centralised in a BI-tool or manually. |
Main idea
A single Peripass tenant can be used by multiple physical plants / sites.
Customers with multiple sites can add as many sites as they want.
A profile, dashboard and kiosk have to be linked to a unique site. This means similar profiles exist on different sites, a profile should be created per site (e.g. Inbound Ghent and Inbound Dusseldorf).
Permissions can be set based on the site (e.g. only execute tasks on a specific site).
Local hardware connections are based on the site the hardware is located.
Won’t do
There is no support for weighing systems together with multiple sites (this is planned in as soon as the first customer is requesting this)
Functional impact of using multiple sites
When adding a visitor to the queue
You are only allowed to add a visitor to the queue of a dispatch dashboard that is on the same site of the visitor.
When configuring a kiosk
Only profiles on the same site as the kiosk can be enabled for registering, weighing and checking out. The connection with local hardware (e.g. for printing of scanning) is realised by the Local Action Worker linked to the site of the Kiosk.
Using permissions with multiple sites
There are not default permission restrictions based on site. You can create your own roles based on the needs to restrict information:
Restrict viewing / creating / editing visitors: use the permissions on profile
Restrict viewing dashboards: use the permissions on dispatch dashboards
Restrict viewing assets: as assets are most of the time shared between sites, we won’t be assigning assets to a specific site and therefore have no way to restrict accessing specific assets using permissions.
Restrict tasks: use the permissions on task management to limit operators to task on a specific dashboard only.
More information on permissions can be found here User management: users, roles & permissions & login
Using Triggers & Actions with multiple sites
When using multiple sites you will typically have 2 types of triggers: triggers for all sites and triggers for specific sites.
Triggers for all sites
These triggers will typically target multiple profiles across multiple sites. For these triggers it won’t be possible to add Local Actions. These are actions that are executed on a local network (e.g. printing a ticket, creating a pincode in the local access control system, …).
Triggers for specific sites
These triggers will typically target one or more profiles within the same site. These triggers can execute Local Actions. These are actions that are executed on a local network (e.g. printing a ticket, creating a pincode in the local access control system, …).
More information on these concepts can be found here: Actions | Cloud-Actions-vs.-Local-Actions
How to set up
Add a new site under Configuration > General Settings > Site
In case you don’t need local actions, just use the same Local Action Worker as your first site
In case you need local actions or scanning/printing on the kiosk: install a Local Action Worker on a server/VM in the network of the local site. Once installed, it should show up in the list.
Copy the Profiles you want to re-use. Change the site and the name. Adapt other settings according to your needs.
Copy the Kiosks you want to re-use. Remove the available profiles for registration and for check-out. Change the site and the name (this won’t be possible before removing the profiles). Add new profiles. Adapt other settings according to your needs.
Go over all Triggers & Actions to see which ones need to be copied and adapted for your newly created profiles.
Different implementation strategies
There are 2 strategies to implement new sites on existing systems.
On a staging area on the production tenant
What: configure on production while ensuring the current users cannot see anything of the changes (create this “Staging area” by limiting permissions of users to see your new configuration).
When to use: This is adviced for all changes that have no impact on existing flows or do not have integrations with 3rd party systems (outside of the Peripass ecosystem)
On a test tenant
What: configure on a dedicated company-test tenant. Create and test all configuration on that tenant. Once tested, manually redo the configuration on the production tenant.
When to use: this is adviced when changes have impact on existing flows or when integrations with 3rd party systems are involved.
Some extra tips:
Keep triggers & actions that connect to a 3rd party system clean and as straightforward as possible.
Instead of having 3 triggers updating SAP, create a process step. Then have 3 triggers updating a process step. Then have 1 trigger update SAP. This way you reduce dependencies and you can test your system easy without SAP as well.
It is wise to combine the strategies depending on which parts of the implementation your are working. E.g. split the project in setting up the new site without external integration. Do this using strategy 1. As a sepate track, implement the integration with a 3rd party and do this using strategy 2.
Be carefull to disable integrations with 3rd party systems when copying your production tenant to a test tenant.