Triggers you need before starting

Note: Our blueprint will contain most of these triggers by default. Despite this, it might make sense to check this list and verify everything is set up the way you want it.

State changes

Most of the state changes will depend on the implementation and should be created with triggers & actions.

Actions that change states automatically can be found in the diagram in this article: Visitor status flow

All other state changes should be realized with triggers & actions.

E-ticket

Peripass will not automatically send E-tickets. You need to configure when you want them to be sent.

Best practices are:

add trigger & actions to send e-ticket
- trigger: when a profile is assigned.
  - Sidenote: “created by” trigger will not work for visitors that are recurring.
- condition: visitor is not blocked
- condition: visitor is last modified by calendar connector / api / import
  - Just keep in mind that the management portal has a dedicated button “save and send e-ticket”. So be sure to skip the created-by-management-portal in this trigger to avoid sending duplicate e-tickets.
add triggers & actions to send a warning to the host in case a visitor is invited that is blocked.
- trigger: when a profile is assigned
- condition: visitor is blocked

Reset transports with a new slot booking back to expected

When a transport in the status WAITING DISPATCH is rebooked to a new slot in the future, it is important that the visitor is reset to the status EXPECTED . If this does not happen the visitor will still be in the status WAITING DISPATCH and he/she won’t be able to register on the date of his new booking.

More info: Public API & Integrations | Automation

🖥️ How to configure

Scope: only logistics profiles
Trigger: “when a visitor is assigned a profile…”.
Conditions: visitor is in the status WAITING DISPATCH or WAITING APPROVAL

Set to expected for recurring visitors

Don’t forget to set potential recurring visitors back to EXPECTED .

Always use a trigger to set all visitors from a specific profile back to expected by default. Reason: otherwise you have to many edge cases where the visitor is not in the right state when required.

Set visitors in “ready for checked out” to “departed”

The status “ready for checked out” is only used in case document handling or a check out process is in place at the customer. If this is not in place, make sure visitors in this status are always pushed towards “departed”.

(visitors will end in “ready for checked out” when the “finish yard operation” button is clicked).

Onsite / Offsite

The behavior of Onsite / Offsite is only changed by Triggers & Actions. Up to you to decide when you want the location to be changed.

ACS Removal

Each visitor created in Peripass should always have a removal as well. The implementation wil depend on the business flows of the customer.

However, you should always add:

Trigger: when status is changed to blocked
Condition: -
Action: delete person in ACS

All > status: Blocked > remove pin

ACS fallback clean-up

It could happen that not all visitors are cleaned up correctly in the ACS System (incorrect configuration, trigger temporarily disabled, …). Over time this could fill up the ACS, which is dangerous since ACS’s have a hard limit on amount of cardholders (visitors with pin or badge or …).

For this it is important to always have a clean-up trigger.

Don’t remove / omit this trigger, since this will again open the door towards “forgotten” removals.

Implementation principle:

We have 1 trigger that will remove the pin-code from all visitors that might be “forgotten” to cleanup
Limitation: the business processes of all profiles in the system should be aligned in that way that there is 1 universal moment in time to remove pincodes. (1)
- e.g. it is impossible to have visitors removed the day after their visit and truck drivers 3 days after their visit
We only remove pincodes for expired profiles. So if a certain visitor should keep his/her pincode, it must still have an active profile.

Solution to implement:

Trigger: at a certain time (preferably during the night)
Condition:
- Validity of visitor's profile expired today/1/2/3 days ago
  - advice is to take 3 days, to cover for the weekend
- Visitor’s active ACS tokens is not empty
  - this is used to avoid running this action for visitors without pincode
Action: delete person in ACS

All > daily at 00:15 > expired 3 days ago & ACS tokens is not empty > remove person from ACS

Some extra’s are possible:

Add check-out action (used for visitors on sites that do not have a clear check-out procedure)

(1) The reason for this is that there is no possibility to add a condition that checks for expired profiles. However for very specific and high demanding customers a workaround is possible:

at 22:00 set a trigger to update a technical dropdown of a customer towards a specific value
after 3 days, check for this dropdown (using conditions) to distinguish visitors from different profiles

When using dropdown fields on visitors which are e.g. not asked on the SSK, the system keeps a NULL as value. This implies a condition check on this dropdown field will never result in a success if it has never been set.

Thus, when using a dropdown field it is important to set a default value yourself. This can best be done on Assigned profile to make sure all visitors have the default value selected.

If no initial value is given in this dropdown (via SSK or T&A), the dropdown is filled with the first value of the dropdown whenever a visitor is edited and saved.