Skip to main content
Share:
Link is copied

Contacts Overview

Contacts Basics

Contacts represent people in the real world to whom an evalink talos workflow can reach out to report an emergency or ask for verification.

A workflow can be configured to reach out to a contact:

  • automatically

    • by email, with a configurable message that contains alarm-specific details

    • by phone or SMS, by means of Twilio integration. Automated phone calls with text-to-speech technology can be used, with acknowledgement / verification using a human-entered numeric code

  • manually, by prompting the operator to contact a person by the provided contact details

Contacts can be created for a site, site group, or Company (global contacts).

tip

A global contact is a contact relevant to many or all sites at once - for example, a technician or an installer that handles the equipment issues for many or all sites. The same applies to site group contacts: these are contacts relevant for several or all sites in the group. A site-level contact is usually a responsible person on a particular site – for example, a guard, a manager, or a landlord.

Only Administrator and Manager can create and manage contacts in evalink talos.

All operations with contacts are described in section Operations with Contacts.

Contact Availability

A contact has availability status: available or not available. Administrator and Manager can set the availability status for a contact manually or automatically (based on the schedule).

See Operations with Contacts > Contact Availability Status for details.

Contact Lists

Administrator and Manager can configure Contact Lists. When a workflow reaches out to a Contact List instead of an individual contact, it tries reaching all people in the Contact List in the order of their priority until someone from the list is contacted successfully – for example, an email or SMS is sent or a call is picked up.

See section Operations with Contact Lists for details.

Contact Roles

Administrator and Manager can configure Contact Roles – placeholders that resolve to a particular contact, Contact List, or a Dynamic Contact (see section Dynamic Contacts) when the workflow runs on a site.

For general information about evalink talos roles, see section Advanced Features in evalink talos > Use of Roles.

Contact Roles typically represent common duties or functions performed by people on many sites, for example, Supervisor, Technician, Landlord, Local police, etc.

Contact Roles are created on a global level and are then assigned by Administrator or Manager to a particular contact, Contact List, or to a Dynamic Contact on the site, site group, or global (Company) level.

When a workflow that contains a Contact Role runs on a site, it first tries resolving the Contact Role on the site level. If the role is not assigned on the site level, the workflow goes sequentially up in hierarchy until the role is resolved. See section Advanced Features in evalink talos > Use of Roles > How a Role Is Applied for details.

A Contact Role, if assigned, is displayed in a bubble in the Roles column of the contact record, see the figures in section View the Contacts of a Site, Site Group, or Company > The Contacts Page.



For details on adding a Contact Role, see section Manage Contact Roles.

Contact and Contact List Overrides

Administrator and Manager can substitute a contact with another contact (or a Contact List with another Contact List) for a certain period of time. This temporary substitute is referred to as an override.

For Dynamic Contacts (see section Dynamic Contacts), overrides are not supported.

For details on how an override looks on the Contacts page, see section View Contacts of a Site, Site Group, or Company > An Overridden Contact or Contact List on the Contacts Page.

For details on creating an override, see section Advanced Operations with Contacts and Contact Lists > Temporarily Override a Contact or a Contact List with Another One.

Dynamic Contacts

evalink talos has a special type of contacts that can each contain a collection of contacts and / or Contact Lists. When used in a workflow, a Dynamic Contact allows to apply contacts / Contact Lists from the collection conditionally – for example, depending on the time of day. Dynamic Contacts are described in section Work with Dynamic Contacts.

The Contacts Page

The contacts and Contact Lists created for a site, site group, or the whole Company, can be viewed on the Contacts page.

See details in section View Contacts of a Site, Site Group, and Company.

Setting Up Contacts: a Summary

The figure below shows which types of contacts can be created and how they can be used in workflows created on different hierarchy levels:

Configuring contacts and Contact Roles: a summary

The setups shown on the figure can be configured by users with Administrator or Manager permissions.

info

The concept of higher-level workflows is explained in section Workflow Types > Site, Site Group, and Global Workflows in Workflow Reference > Workflow Types.

For definitions of a Standard and a Managed Workflow, see section Workflow Types > Standard, Managed Workflows, and Workflow Templates in Workflow Reference > Workflows Overview.

First, consider which workflows will involve contacting someone in case of emergency.

In most cases, a workflow involves contacting a responsible person (or a number of people) with a certain defined function – for example, a technician, a landlord, police, fire brigade, etc.

  1. If the necessary function is performed by a separate person on each site / site group:

    a. Create a Contact Role for each such function

    b. Create contacts and Contact Lists for each concerned site and site group, assign Contact Roles to these contacts and Contact Lists

    Contacts / Contact Lists are added on the Contacts page of a site or a site group (see section View the Contacts of a Site, Site Group, or Company > The Contacts Page).

    For details on creating a contact / Contact List and assigning a Contact Role to it, see sections Operations with Contacts > Create a Contact and Operations with Contact Lists > Create a Contact List.

    c. Create an appropriate workflow that uses each Contact Role. The following types of workflows can be created:

    • a higher-level Standard Workflow

      When using this option, make sure that the alarm that triggers a higher-level Standard Workflow can be received by the respective workflow only. For details, see the INFO under the list.

    • a Managed Workflow

      tip

      The main difference between a Managed and a Standard higher-level Workflow is:

      • a Managed Workflow needs to be linked to a site / site group in order to be applied when an alarm for the respective site comes in

      • a higher-level Standard Workflow can be applied without linking, if the alarm matches the workflow incoming conditions and if the alarm is not consumed by another workflow, as defined by the workflow priority rules (see above)

        The rationales for using each of these workflow types are described in section Workflow Types > Standard, Managed Workflows, and Workflow Templates in Workflow Reference > Workflows Overview.

      Workflows are created on the corresponding Workflows page. For details on workflows, see section Workflow Reference > Operations with a Workflow > Work with Workflows).

  2. If the necessary function is performed by the same person or persons on all your sites (for example, an evalink talos support engineer), create a global contact or Contact List and use them in a global Standard Workflow.

    Global contacts and Contact Lists are created on the Company > Global Contacts page. For details on the creation procedure, see sections Operations with Contacts > Create a Contact and Operations with Contact Lists > Create a Contact List.

    When using this option, make sure that the alarm that triggers the current Global Workflow can received by this Global Workflow only. For details, see the INFO below.

info

When using higher-level Standard Workflows, make sure that there are no local (site) workflows with the same or similar incoming conditions – the ones that can consume the alarm that should trigger the current higher-level workflow. If the alarm is consumed by a local (site) workflow, the higher-level workflow is never triggered.

For Manual Workflows (see section Workflow Types > Manual and Automated Workflows in Workflow Reference > Workflows Overview), if there are competing local (site) workflows, a higher-level workflow can be configured to take precedence over local (site) workflows.

For details on alarm consuming and workflows priority, see section Workflow Reference > Workflows Overview > Alarm Consuming Priority.

With Dynamic Contacts (see section Work with Dynamic Contacts > Dynamic Contacts Overview), the decision flow is different. See section Work with Dynamic Contacts > Dynamic Contacts Overview > Using Dynamic Contacts: a Summary for details.

Was this page helpful?