Bots: The Essentials

A bot defines the automation you want AppSheet to run:

when something happens (an event),

perform a set of activities (each activity is a task and a set of tasks is a process).

Bots can perform a wide variety of functions. For example:

• Create and send an email, SMS message, or notification regarding the modified record.

• Further update the modified record.

• Update the parent record of the modified record.

• Add, update, or delete child records belonging to the modified record.

• Call a webhook to invoke an external web service.

You can perform a wide variety of other functions because once the bot is triggered, it is capable of working on any table and doing almost anything. Once enabled, bots run in the background to listen for events or trigger processes on a schedule even when you are not directly using an app. To terminate the process automation, you can disable the bot.

For example, the Employee onboarding bot is configured to trigger the Onboard new employees process anytime a new employees record is created. The bot continues to listen for the new employee creation events and fire the associated process when the event occurs until it is disabled.

How bots are triggered

Bots can be configured to trigger a process based on a data change event or according to a predetermined schedule.

Bots with data change events

You can create bots that are triggered by a data change event, such as:

• Data is added, updated, or deleted. For example, you can trigger a bot when:

  • A new row is added.

  • An existing row is updated. For example, the update may occur as the result of editing a row in a form view, or performing a quick edit, or invoking a client action through a user button click.

  • An existing row is deleted.

• A data change action is invoked on the AppSheet client.

• An add, update, or delete is performed using the AppSheet API.

The data change that triggers a bot can be any type of data change that arrives at the server. For example, you can add an extra table column whose only purpose is to trigger a bot. Then, you can create a client action button that updates the extra column's value. Clicking the action button triggers your bot.

After the data change is synced to the server, AppSheet:

1. Makes the appropriate changes to the spreadsheet or database.

2. Ensures that any formulas in the spreadsheet are re-computed to use the latest data values.

3. Determines whether your bot should be triggered.

To further restrict when a bot is triggered, you can specify the following:

• Type of data changes that trigger the bot when configuring the event. For example, you could trigger a bot:

  • Only when a row is added

  • Only when a row is updated

  • Only when a row is deleted

  • Only when a row is added or updated

  • When a row is added, updated, or deleted

• Condition that triggers the bot when configuring the event. For example, you could trigger a bot when:

  • A new row is added to the Inspections table, and the value in the InspectionPassed column is FALSE.

  • A row is updated in the Orders table, the value in the OrderAmount column is over $500, and the value in the DeliveryDate column is within 10 days of the current date.

• Whether a bot can trigger other bots and, if so, whether to sync data changes only after this bot and all bots that it triggers complete their execution when creating a bot.

Note: In some cases, user access to table data is limited for security reasons as governed by security filters on the table. AppSheet provides the ability to enable a security bypass to allow access to the table data strictly for purposes of evaluating the condition to determine whether the bot should be run.

Bots with scheduled events

Alternatively, you can use a bot that is triggered on a schedule you specify. Just like a data change-triggered bot, a scheduled-triggered bot is capable of working on any table and performing a wide variety of functions. See Understanding bot scheduling and retry.

How bots are not triggered

Bots are not triggered by:

• Changes made directly to the spreadsheet or database
  Changes you make directly to the spreadsheet or database do not go through the AppSheet server, so they do not trigger AppSheet bots. For example, if you update a Google Sheet directly, Google Sheets does not notify the AppSheet server about the change. Since the AppSheet server is unaware of this change, it does not trigger any AppSheet bots.

• Data change actions invoked by a bot unless that bot that makes that data changes has been explicitly configured to trigger other bots.
  Data change actions that are invoked by bots do not trigger other AppSheet bots. For example, if a client device performs an add, update, or delete that triggers a bot, and that bot invokes a data-change action, that data change action will not invoke any bots.

• Changes made through another AppSheet application, even if that application is using the same underlying spreadsheet or database table
  This is true even if the two AppSheet apps share the same underlying spreadsheet or database table. For example, you might have a Payroll app and a separate Personnel app that share an Employees table. Bots defined in the Payroll app will only be triggered by adds, updates, or deletes to the Employees table that are performed through the Payroll app. Adds, updates, or deletes to the Employees table that are performed through the Personnel app will not trigger workflow rules defined in the Payroll app. In short, bots only work within a single AppSheet app; they do not work across two or more apps, even if those apps share common underlying spreadsheet or database tables.

Application version and bots

Each time you change your application, AppSheet creates a new version of your application. These changes may include changes to your bots.

AppSheet includes the application version each time a user submits their adds, updates, or deletes to the server. This is essential because the user may be submitting changes based on an older version of your application.

When invoking bots, AppSheet invokes the version of the bots that match the user's version. This may result in invoking an older version of your bot. You can detect when this occurs by examining the audit history. The audit history includes the application version number.

After the user has submitted their changes, the AppSheet client performs a sync that retrieves the latest data and application version. Any future changes will be submitted using that application version.