Something not working as expected? Amazon Honeycode has errors and warnings to help you debug any issues with automations.
General error: An automation will not publish/run successfully
Formula error: There are invalid syntax or references in a formula
Configuration error: There are invalid or missing inputs outside of a formula
Warning: There are potential issues that have been flagged but don’t block publishing
If you are a builder and notice one or more errors or warnings while building automations, look out for configuration or expressions errors or warnings. In this section, we will cover build time validations.
Automations are validated in Honeycode by checking the automation against the first row in the source table referenced by the formula. Given that columns are formatted homogeneously by format type or formula, if there’s a warning in the first row, you know that the warning applies to all rows in the source table.
Whenever you see an automation warning, check out the first row in the related table to help uncover the issue.
An error occurs when an automation or its inputs are invalid and cannot be published.
If a workbook automation contains an error, your updates will save. However, you must fix any errors in order to successfully publish and run the automation. If unpublished, the automation will not run.
- If a workbook automation contains an error, any changes made by the user in the current automation will not be published
- If an app automation contains an error, the automation will publish, but it may cause your app automations to break
The first type of error can occur in formulas. If there’s an error in a formula in an automation, you’ll see the error in-line, as you do with any formula in Honeycode.
Follow the formula help to fix the formula error. You’ll know the error has been corrected when you see the error indicator switch to a blue dot in the formula field.
The second type of error that can occur in your automation are configuration errors. Configuration errors account for inputs that are not formulas.
For example, if one or more mandatory input fields is missing or incorrect, the automation will be invalid, and you’ll see an error indicated in the header. Clicking on the error icon will show more details, so you can go to the field where the error occurs to make the appropriate fixes.
In your workbook, you’ll be able to see the configuration errors in the top-right corner as well.
For app automations, you can see the error indicated by a red dot in the app action header, as below. Click to see help on how to fix the error.
Warnings let you know that there could be a problem with your automation. Warnings are generally related to potential changes in your data model.
Unlike errors, warnings are non-blocking, meaning the automation will still run, regardless of the warning. However, it’s a good practice to look into these warnings so they don’t become issues down the road.
In the case of formulas, a warning signals that the automation returns a result other than what is expected. Look for the indicator to the right of the formula field.
Blue dot: Formula evaluates correctly
Blue circle outline: Warning
Red exclamation: Error
In the example below, one formula shows a warning, indicated by an unfilled blue dot. The formula underneath has a filled blue dot that indicates the formula evaluates correctly.
Unlike workbook automations in tables, which have to published to run, app automations are live updating. If you want to edit an app automation but aren’t ready to make the updates live, there are a couple methods you can use to do this.
For app automations that have traffic, aka are in use, you can use an app object’s visibility settings to test your changes before you can merge them to the live version. Here are the steps you can follow:
- Make a copy of your app object whose automation you want to change and also test the changes.
- Name your copy as app_object_copy.
Set the visibility of app_object_copy to
=TRUEonly when the SYS_USER is same as the person who is debugging the app automation.
- Make changes in app_object_copy and view them in your app on mobile or web. The app_object_copy is visible only to you.
- Once your changes look good and you are ready, remove the formula in Display > Visibility to make copied app object visible for all app users, or replicate similar changes in your previous app_object.
- Delete your previous app_object.
- Appropriately rename app_object_copy, or if you replicated changes in your app_object, delete the copy.
- Your tested changes are now live to your app users.
In the example below, the button is only visible to the user in the “Name” column of the “Users” table.
This ensures that only you can view the changes. Once you think the changes look good, you can make it available to all of your app users.
A quick and easy technique to test notifications is to set yourself as the recipient. You should receive both an email notification and an in-app notification. You can use this method in tables, as well as app automations, to test that your automations are executing as expected.
Want to skip running one or more blocks in app or table automations? Run Options provides a quick way for you to skip one or more steps in automation.
If you want to disable a block, set the condition to
=FALSE to ensure that execution of the block is skipped while automation continues to run.
However, keep in mind that since this step skips running, if you need to test changes for your app automation, we recommend that you look at “Testing app automations” section of this article.
Having trouble running your automations? It is possible that one or more of your automations which published successfully in the past will fail to run. Look for the following cues to help troubleshoot your automations.
The system restricts some circular automations to avoid infinite loops or run way automations.
A workbook automation with a date/time trigger is failing to run.
Currently, there are two ways of setting up date/time triggers:
- Set on a fixed date/time, e.g., 8/27/2020
- Set on a row date/time, e.g.,
Remember that a date/time triggered automation runs once for each row in your table. So if you have a large table with over 100,000 rows, the automation is not guaranteed to run for all rows in the table.
If you notice that one or more of your date/time triggered automations fails to run, it could be related to the size of your table. If your use case requires date/time triggers for all rows in a table to run simultaneously, we recommend that your table does not contain 100,000 rows or more.
Not all email notifications and in-app notifications are delivered to recipients.
Notifications can only be sent to people and groups in your team formatted as contacts. Emails entered as free-form email addresses are invalid.
Check your recipients field to ensure all recipients are contacts suggested in the dropdown menu.
One or more workbook or app automations in a chain fails to run.
A chain is when one automation triggers another automation.
Let’s say you have a date/time trigger whose action is “Add a row.” This starts another automation whose trigger is “Row added’ and whose action is ”Update a column.“ This then starts another automation whose trigger is ”Column changes“ and whose action is ”Notify,“ and so on.
You can create multiple actions and triggers within the same automation. If you wish to edit or add to an exiting automation, you can do so at any time.
We recommend you to be cautious of scenarios that create a chain of individual automations. Chaining of 1000 or more automation is not currently supported. If you are experiencing issues running automations and you suspect it might be related to chaining, please report the issue in Honeycode.
Previously published automations on date/time reached trigger stop running after duplicating a workbook.
That is a currently a known gap in Honeycode. We are working to fix this issue.
Until this issue is resolved, we recommend you manually publish automations in the duplicated workbook.
Email notifications and in-app notifications triggered by date/time are not received when expected.
Date/time triggers are meant to be run at the time specified in Universal Coordinated Time (UTC).However, our system adds a possible delay of up to one minute when running these automations.
Check that you have set your automations to UTC. To calculate UTC in your time zone, subtract how many hours your time is off from UTC. For example, UTC - 8 hours = PST. If your times are set to UTC and you still notice delays of more than one minute, please report the issue in Honeycode.
A workbook or app automation that was previously working stops running.
Changes to your data model can impact the source and destination for triggers and actions, and can cause an automation to stop running.
Start by checking for errors or warning in your automation. Then, check the automation’s trigger source, whether it’s a table/sheet, column or cell. Follow up by checking the action’s destination table.
Is the user is added to workbook via Group Sharing, it is possible that a formula that uses the system variable SYS_USER will not run as expected and return an error. This is a known issue.
Due to a current gap in our system, SYS_USER system variable seems to return #ERROR! in automations when the workbook collaborator was added via group sharing. Remember, you can continue to access the workbook, and build and run automations as expected. The only impact is the SYS_USER variable to return an error.
Follow either of these steps to remedy the issue:
- Make sure you load or run one or more of your apps in the workbook shared with you via group sharing.
- Make sure to make an entry for your own contact format in one of the workbook tables shared with you via group sharing.
Either of these options can help unblock the SYS_USER system variable to return the expected value.
Workbook or app automations are running more slowly than expected.
There could be a number of reasons that automations are executing slowly.
There could be a number of reasons for this. First, check the size of your iterator. The iterator condition defined in Run Options > Run the step for these rows returns a set of rows called an iterator. The automation action is run once for each of the rows iterator. If the iterator size is very large, you might notice an additional slowness in running of your automations.
If you notice that your automations fails to run and your iterator size is in thousands, we recommend that you tweak the iterator size to ensure successful run.
One of the more uncommon reasons an automation will fail to run could be due to system limits.
If you believe your automations are well below system limits and you are experiencing a failure, we encourage you to report the issue.
If you want to make sure your automations are running and working correctly, you can check by viewing the Run History.
There are two ways to access your workbook's run history through the Automations modal and the Builder modal:
- Click the lightning bolt on the left side bar to access the Automations screen
- Click the Run History button.
- Click the layered squares on the left side bar to access Builder
- Click on the app (assuming you might have more than one)
- Click the screen that has the app object
- Click on the app object that triggers an automation (e.g. a button)
- Click the Actions tab on the properties panel
- Click Edit automation
- Click the Run History button that populates above the formula bar.
On the run history screen, you can view the following:
- Start time in UTC: The date/time in Coordinated Universal Time (UTC) that the automation execution began.
- Name of the automation: For automations in the table/sheet it will provide the name. For app automations, the name will be the name of the app object that has the automation attached.
- Location: This is the name of the table/sheet for which the table automation ran. For apps, it is the app name and screen name where the app automation lives.
Status: This indicates if the automation ran successfully or if there were failures. There are three states that we support:
- Successful: if the automation ran successfully.
- Failed: when the automation failed to run. Honeycode provides insights to the formula or expression that failed.
Completed: This status is special and is applicable only to automations with a notify block. In cases where an automation runs completely, there is a possibility that among some recipients in the notify block, one or more notifications failed to send. In this case, while the automation completed successfully, at least one of the recipients failed to receive the email.
For a custom view of your run history, you can:
- Clear Filters: By default, the run history will show for the particular automation you accessed. For a global view of the entire workbook's automations, you can click Clear Filters in the upper right part of the screen.
Filter results: You can filter the results by clicking on the triple line icon next to the column title for each of the following:
- Start Time (UTC)
Which automations does Honeycode track run history for?
- Honeycode will track the run history at a global level for all of your workbook's automations; furthermore, Honeycode tracks run history for both table and app automations. For example, a table automation that adds a new row to a table as well as an app automation that sends out an email notification when a button is clicked will both be tracked.
How long does Honeycode keep track of my automations run history?
- Honeycode will track run history for 30 days, and the results are ordered by start time with the most recent at the top. Note: It is possible to see an automation from the past under a name that has since been renamed, modified, or deleted.
|Was this article helpful?|