Skip to main content

Configuration

A package is the unit of automation in the automator. It contains a script, written in AutomatorScript, together with the settings that determine when it runs, which libraries it uses, who to notify about errors, and so on.

Because you will spend most of your time writing and maintaining the script, it has been placed in a separate "Script" tab. All the other fields of a package are placed in the "Settings" tab.

The "Script" tab also contains toggles for viewing the logs of previous package executions and a button to manually execute a test run, as explained on the Testing page.

Available fields​

On the "Settings" tab, the following fields can be configured:

  • Name - the name of the package.
  • Description - a short description of the package. Note that, as a convention, the summary of the package and overall version history is typically placed in the script itself, as a header comment.
  • Package type - see below

For packages of type "Standard package" and "Test package", the following fields are also available:

  • Libraries - the libraries that the package uses, explained in Libraries.
  • Triggers - what causes the package to run, explained in Triggers.
  • Enabled - whether the package is enabled or not. If a package is disabled, it will not respond to any triggers.

Standard packages also have the following fields:

  • Log level - one of "Debug", "Verbose", "Info" or "Error". This determines the minimum level of messages that will be logged. For example, if you set the log level to "Info", then messages generated by logDebug and logVerbose will not be logged.
  • Send error emails - whether to send an email to the configured email address(es) when an error occurs.
  • Allow webhook events triggered by the API user - see below.
  • Enable sequential execution - see below.

Package type​

There are five types of packages:

  • Standard package
  • Standard library
  • Environment library
  • Test package
  • Test library

Choose the "Standard package" type for the entrypoints of your automations. A standard package can have triggers and can be executed, unlike libraries.

Typically, one integration corresponds to one standard package. For point-to-point integrations, you usually have two standard packages: one for the integration from system A to system B, and another one for the integration from system B to system A.

If you have integrations for multiple different record types, you can create a standard package for each record type, for example one package to synchronize requests, and another to synchronize projects.

To organize code in reusable units, you can create libraries. See libraries for additional information, including details on the package types "Standard library" and "Environment library"

The package types "Test package" and "Test library" are used for automated testing and are explained here.

Webhook events triggered by the API user​

The checkbox "Allow webhook events triggered by the API user" is specific to Xurrent-to-Xurrent integrations that are triggered by a webhook and is used to prevent automation "loops".

When configuring the package trigger, in addition to the webhook event type, you also have to specify the automator account it is associated with, which, in turn, contains the details of the connection to Xurrent, including the OAuth or bearer token credentials to use. In Xurrent, these credentials are always linked to a person record, and we refer to this person record as the API user.

Updating a record in Xurrent will trigger a webhook event. In a Xurrent-to-Xurrent integration, the integration itself updates records in Xurrent through the API user's credentials, and this also triggers webhook events.

If this would also trigger a package to run, it's easy to create an automation loop, where each package execution causes yet another execution.

The checkbox "Allow webhook events triggered by the API user" can be used to prevent this, and by default it is unchecked. It looks at the person_id field of the webhook payload to determine whether the webhook event is triggered by the API user.

If you are sure that automation loops are not possible in your scenario, and/or you don't want special handling for the API user, you can check this option.

Sequential execution​

When the option "sequential execution" is enabled, only one execution of a package can be processing at a time. This can be very useful, for example, when a package is handling both creates and updates of records, and you want to ensure that the creation is finished completed before the update is attempted.

To avoid clogging the queue for events triggering this package, however, we recommend that you use this feature judiciously and limit its use to short-running packages, or packages with a relatively small number of events.