Triggers
There are a lot of different triggers in Peripass. These are documented in the application itself. Good use cases for automations are spread through our knowledge base. You can recognize them typically by these titles: ⚡Automation.
We make a distinction between triggers related to visitors and triggers related to assets.
When using asset management, you might need following rules:
Configure different actions based on the visitor’s operation type. For example sending distinct text message for live loading versus for drop-off empty and pick-up full
Apply appropriate asset conditions when setting up visitor triggers
Automate actions on assets even when no visitor is attached, such as creating shunting tasks when the asset status is updated
Use asset triggers to define actions for specific asset events.
For more details, visit: Yard Asset Management | Automation
On this page we only highlight some trigger that might need a little bit of extra explanation:
Visitor related triggers
At a certain time / every certain amount of time
Most triggers are fired when something changes to a visitor. In that case all actions will be executed on that same visitor.
Time-based triggers work differently. They will fire at their programmed intervalls and will execute actions for all visitors that meet the conditions.
Time based triggers can overload the our systems, because of that it is important that the scope of a time based trigger is limited. Applicable limitations:
Fixed time trigger: max 1000 visitors
Periodic time trigger:
Period <= 15 minutes: max 100 visitors
Period > 15 minutes: max 1000 visitors
Important
When time triggers are saved, a warning message will be displayed if the current scope breaches the limit.
When a trigger breaches the limit an error is logged in the event log and the actions are not executed.
When a trigger breaches the limit 5 consecutive times, the trigger is automatically disabled and a mail is sent to support.
When a visitor’s status changes
This trigger must be used for triggering dispatch actions. Also when redispatching, the status will be changed from checked in to checked in.
Please note that this trigger has a dedicated condition (Position in te sequence of a combined transport) when combined transports is configured for the tenant. The main use case is to differentiate the automation for first dispatches than for redispatches when handling with combined transports. More information can be found here: Combined Transports | Send-different-SMS’s-on-redispatch
When a dispatch dashboard dock was assigned (depreciated)
Do not use this trigger anymore. Use “status changed to checked in” instead.
When a visitor is assigned a profile
This has an extra property that determines when it will fire:
Fire fore new assigned profiles
This trigger will fire when a new profile is added
Fire fore new + updated assigned profiles
This trigger will fire when a new profile is added
Or when an assigned profile is changed to a new profile
Or when an assigned profiles validity changes
This trigger will never fire when the source of the change is an Action
To avoid endless loops, this trigger will never fire when the change was caused by another Trigger + Action.
Use this trigger to initiate actions for new visitors (e.g. sending e-ticket).
Use this trigger to change profiles of visitor pushed to Peripass from an external tool.
When a profile is changed to the same profile
When a process step changes
Use this trigger in combination with a process step custom field to create your own statusses and automate flows based on them.
When the (nearby/remote) queue of a visitor changes
Use this trigger to send a text message to inform the driver they can approach to the nearby waiting parking.
This trigger will only fire when the queue is changed from nearby to remote or the other way around.
If you need a trigger when a visitor is added to a dispatch queue for the first time, then you can use the status change to “waiting dispatch”.
When a visitor was able to access
Special case:
When 2 visitors register with the same license plate, Peripass cannot know which visitor is the correct one. Therefore we decided that Peripass will always trigger an access entry event for the visitor that registered last with this license plate.
Reasoning: We have learned that in most of the cases when this happens, this is caused by returning trucks that did not properly check-out on their first visit. Therefore the last registered is more relevant that the one that was not checked out.
Asset related triggers
When the asset’s status changes: offsite, toLoad, toUnload, FinishedEmpty, FinishedFull
When the asset’s location changes: the asset is moved
When a task related to the asset is finished
More information can be found here: Yard Asset Management | Automation