Automation Record History
With each new product improvement released, app builders in our community push the limits of what the Quick Base platform can do. Since early access was announced in March of this year, Automations have been at the heart of this push, allowing customers to accomplish more with less clicks in their application ecosystems. Our product and engineering teams have been hard at work to improve the capabilities, reliability, and speed of Automations pursuant to our Power product theme.
This part of our platform continues to evolve, and we're actively listening to customers who have adopted Automations to solve problems in their increasingly complex business environments. We are aggressively adding to and checking off items on a capability wish-list for Automations. Currently,one such item is that actions originating from an automation set the affected record's [Last Modified By] and [Record Owner] fields as the person who owns the Automation. But what if you want to see the name of the user who triggered the automation to run?
Let's say you have a project management application with a Projects table that has a related child table(let's call it Project Changes) that is intended to be a history of what has happened on each project throughout its life cycle. You build an automation that triggers each time certain fields are changed on a project, with an action that creates records in Project Changes showing those, well, changes. Say you also want to automate a relevant business rule: when a project's status changes from "In Progress" to "Completed", all tasks (in another related child table -Tasks) are also set to "Completed".
Alright let's think this through. The person who made the changes to each project (the parent table)will show as the owner and the last modified on each of the records in Project Changes (child table). That seems like what we want. However, on the Tasks table, it will say the person completed one or more tasks that they may not have intended to complete. Even if they know the business rule well, they may not know that the automation covertly posed as them. On small teams this might work out fine; the automation owner can simply let the end users know how the app works. However, if there is likely confusion in this very simple scenario, large teams with much more complex scenarios could cause even more confusion.
To track who triggered an Automation, we'll create two additional user fields (one in the parent table and one in the child table), and an automation with two actions. The first action updates the triggering record with the user who made the triggering change. The second action passes that user down to the affected records.
Here's a step-by-step:
1. Create 2 new fields:
a. Projects (parent table) - [Project Changes Trigger] - user type
b. Project Changes (child table) - [Modified by Automation] - user type
2. Create an Automation called "Project Changes",triggered by criteria your use case requires on the parent table.
a.Create the 1st action to set the field in step 1a as the [Last Modified By]. Be sure to use the condition that the Record ID# matches from the trigger. This tells the action to modify the same record that triggered the automation:
b. Create a 2nd action that add records to your child table, and sets the field in step 1b as the value in step 1a
c. Set any additional fields that you want copied down to the child table
The result will be a child table that shows the user that triggered this automation:
Though the topic of this article is Automations, Webhooks and Quick Base Actions that create or edit records change those record's [Record Owner] and [Last Modified By] fields to the owner of the respective Webhook or Quick Base Action. A similar method to the one above could be employed for these two features as well.
For reference, here is a link to this topic in User Voice, and here is one of the posts that captures a related issue on our Community forum.
This part of our platform continues to evolve, and we're actively listening to customers who have adopted Automations to solve problems in their increasingly complex business environments. We are aggressively adding to and checking off items on a capability wish-list for Automations. Currently,one such item is that actions originating from an automation set the affected record's [Last Modified By] and [Record Owner] fields as the person who owns the Automation. But what if you want to see the name of the user who triggered the automation to run?
Let's say you have a project management application with a Projects table that has a related child table(let's call it Project Changes) that is intended to be a history of what has happened on each project throughout its life cycle. You build an automation that triggers each time certain fields are changed on a project, with an action that creates records in Project Changes showing those, well, changes. Say you also want to automate a relevant business rule: when a project's status changes from "In Progress" to "Completed", all tasks (in another related child table -Tasks) are also set to "Completed".
Alright let's think this through. The person who made the changes to each project (the parent table)will show as the owner and the last modified on each of the records in Project Changes (child table). That seems like what we want. However, on the Tasks table, it will say the person completed one or more tasks that they may not have intended to complete. Even if they know the business rule well, they may not know that the automation covertly posed as them. On small teams this might work out fine; the automation owner can simply let the end users know how the app works. However, if there is likely confusion in this very simple scenario, large teams with much more complex scenarios could cause even more confusion.
To track who triggered an Automation, we'll create two additional user fields (one in the parent table and one in the child table), and an automation with two actions. The first action updates the triggering record with the user who made the triggering change. The second action passes that user down to the affected records.
Here's a step-by-step:
1. Create 2 new fields:
a. Projects (parent table) - [Project Changes Trigger] - user type
b. Project Changes (child table) - [Modified by Automation] - user type
2. Create an Automation called "Project Changes",triggered by criteria your use case requires on the parent table.
a.Create the 1st action to set the field in step 1a as the [Last Modified By]. Be sure to use the condition that the Record ID# matches from the trigger. This tells the action to modify the same record that triggered the automation:
b. Create a 2nd action that add records to your child table, and sets the field in step 1b as the value in step 1a
c. Set any additional fields that you want copied down to the child table
The result will be a child table that shows the user that triggered this automation:
Though the topic of this article is Automations, Webhooks and Quick Base Actions that create or edit records change those record's [Record Owner] and [Last Modified By] fields to the owner of the respective Webhook or Quick Base Action. A similar method to the one above could be employed for these two features as well.
For reference, here is a link to this topic in User Voice, and here is one of the posts that captures a related issue on our Community forum.
