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.

Standard packages also have the following fields:

  • 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.
  • Log level: one of Debug, Verbose, Info, Warn 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 a user of the account: see below.
  • Enable sequential execution: see below.

Of these fields, test packages only have Libraries.

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 a user of the account​

The checkbox Allow webhook events triggered by a user of the account 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 and the 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 a user of the account.

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 account'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 a user of the account 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 one of the users of the account. Packages that allow these events can recognise them with Execution.isTriggeredByAccountUser().

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

Sequential execution​

When the option Enable 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 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.