List of Questions

Hi @prithpal

Actually, I posted series of my qustions which have been accumulated so far onto the QA space in the previous semior, but yet seeing answers and advice. I believe those type of question could be presented to you, as specialist for Automation. Subjet to your time, it is greatful if we could see your answers and clairication so that we understand anatomy more deeply and precisely.

– List of Questions –

• What is the initial input set ups of ADD/LOOK UP? does? In case we set it to ADD, and select [ID] : [ID], it actually update the existing row, now to ADD. Likewise, we set it up to LOOKUP, but add [ID] : Uniqueid(), it actually not update, but just ADD. Either set , ADD or UPDATE, the we do not pass ID field to initial input, but pass other non-ikey column, it will always ADD the row.

• Adding step for returning value, there are two ways to achieve. One is to add step to return value (naked return value), in other way, is to separately create process which wrap a step for returning value, then we call this process rather than adding naked one. On those two different cases how, can we call the returned value, with step name . variable notion. Same dot operator will do the jobs?

• Modularity sounds good, but actually it causes the problems in practical sense when we edit apps. Copy BOT operation is super dangerous. We simply assume that the BOT is duplicated as well as the Process inside the source BOT is going to be copied. But it is not. When we work on the copied bot then apply changes, the same change is going to be applied to the source bot, as process, tasks are shared across multiple BOTs. How can we avoid?

• One we start to work on new BOT, we keep creating new task, process etc, most likely the app creators without knowing. In the middle of working on new BOT, I abort the jobs and delete the bot. BOT is deleted, but the task, actions, process BOT generating process generated until then still alive. How can we delete those task/actions/process along with BOT itself, provided that such task/actions/process will not have any dependency, i.e. not being employed in other BOT or places? We found out it is frustrating and things are messed up at the end, once we create new bot, and stop, delete and open new BOT and abort it, then we will find bunch of Actions, Process tasks, basically we don’t know which one is right ones and ones we NEED to delete. Need a guidance to avoid such a messy situation. And what is going to be the BEST PRACISE to avoid such a mess.

• Step of “Branch on a condition” is taking the values from the immediate parent steps? Without input? Or it may take the row values from row at the time event is triggered?

• Step of “Branch on a condition” can be used like a data change event listener? Let s assume we add step right after step of call a Process which and where task will do change value in a row. Right after that we add new step for “Branch on a condition”. For this yes/no check expression, the expression like we used to use in workflow event, like [Co1].[_thisrow_after]<> [Co1].[_thisrow_before] kinds of expression would work? If this returns TRUE, do another bits and pieces. IF false, what is the best option with us to stop the whole operation. Just return value, STOP or something, which will not gonna be used anywhere though?

• Based on the past experiences with action/workflow, our understanding is that action will only change the values in target row and field. But now, my understanding is that STEP will do add new row as well as update row value operation as well, which is bit confusing. What is the intention and notion behind that step is now capable of changing (update) row value as well as add new row?

• I have BOT1 which is set to Table1. Another BOT2 is sitting on Table2. Also we have table 3.BOT1 will change the value in Table2. BOT2 will change the value in Table3. BOT can trigger another bot, so once BOT1 is fired, then BOT2 could be run as well. However, can we wrap those BOT1 and BOT2 into one BOT? In this single BOT, how can we set it up to run BOT2 inside single BOT? BOT2 will not have data change event listener… But need to be fired when Table 2 value is changed. Is it technically impossible to wrap to single app, but need to stay with 2 separate BOT?

• Hypothetically, BOT could run into infinite loop. The easiest case will be BOT is triggered by update row / field. This bot will do change the field value. Once this BOT is run, BOT will not be re-run otherwise, BOT will be keep updating row forever. BOT will not be re-triggered by data change event which is caused by themselves? I tested with simple scenario, but BOT only run once. I just wanted to know why it happens. (and infinite loop NOT happens)

• BOT is not able to change usersetting values, but is it on the roadmap?

• Once multiple BOT is prepared, then we don’t know which tasks, process are depending on other BOT etc. Need to get the relational maps to see visually the relationships. Ideally, we wish to see from task, process side that what BOT is associated with them. IF nothing, then we could delete easily when we need to clean up.

@Takuya_Miyai

7 Likes

“No-code”.

7 Likes

@prithpal

Please allow me to add one more quesion to the list.

・Using AppSheet API, we are able to invoke action which will change data, edit and/or add new row. Is AppSheet BOT will be monioring such a data event as well and then invoke the BOT triggerd by the event (data change) made by AppSheet API?

Im sorry for presenting tons of questions at one time, but your input is greatly appreciated. It would be also benefit for other community member who may visit this thread.

Hope I will be guided .

Koichi

@praveen

4 Likes

My reaction when i see Koichi san asking questions

6 Likes

Yes that should work @tsuji_koichi

Hi @prithpal
Thank you. I suppose your answer is given to my additional and last question here in the thread, appsheet api is going to invoke bot by data change event?
What about the rest of questions ?

Appreciate for your clarifications .

[quote=“tsuji_koichi, post:1, topic:44508”]
– List of Questions –

Answers inline

• What is the initial input set ups of ADD/LOOK UP? does? In case we set it to ADD, and select [ID] : [ID], it actually update the existing row, now to ADD. Likewise, we set it up to LOOKUP, but add [ID] : Uniqueid(), it actually not update, but just ADD. Either set , ADD or UPDATE, the we do not pass ID field to initial input, but pass other non-ikey column, it will always ADD the row.

This is working as designed. See the explanation below:
These are the options for “Add or lookup process input?” that can be used in a task of type “Call Process”:
a) Add - In this case a new record will be created using the data you supply. If another record exists with the same primary key, that record will be updated and used.
b) Lookup - In this case the record if you supply the primary key then the data will be retrieved using the primary key. Any additional columns will be used to update the record.

• Adding step for returning value, there are two ways to achieve. One is to add step to return value (naked return value), in other way, is to separately create process which wrap a step for returning value, then we call this process rather than adding naked one. On those two different cases how, can we call the returned value, with step name . variable notion. Same dot operator will do the jobs?

Today we support using return values from a child process in the main process using the [ParentProcessStepName].[ReturnValuefromChildProcess] notation, see an example here. We are adding support for steps in a process to be able to access values from previous steps in the same process.

• Modularity sounds good, but actually it causes the problems in practical sense when we edit apps. Copy BOT operation is super dangerous. We simply assume that the BOT is duplicated as well as the Process inside the source BOT is going to be copied. But it is not. When we work on the copied bot then apply changes, the same change is going to be applied to the source bot, as process, tasks are shared across multiple BOTs. How can we avoid?

Re-usability does have good benefits but understand that it adds some complexity. We have made some enhancements to the UI to indicate when components are being reused (for eg: if you go to the task page, we show where all the components are used. If you try to delete a task that is used by multiple processes you will have a prompt that lets you know that you are deleting a shared component. It seems like there are additional opportunities for improvement (in the bot interface) and will definitely explore those.

• One we start to work on new BOT, we keep creating new task, process etc, most likely the app creators without knowing. In the middle of working on new BOT, I abort the jobs and delete the bot. BOT is deleted, but the task, actions, process BOT generating process generated until then still alive. How can we delete those task/actions/process along with BOT itself, provided that such task/actions/process will not have any dependency, i.e. not being employed in other BOT or places? We found out it is frustrating and things are messed up at the end, once we create new bot, and stop, delete and open new BOT and abort it, then we will find bunch of Actions, Process tasks, basically we don’t know which one is right ones and ones we NEED to delete. Need a guidance to avoid such a messy situation. And what is going to be the BEST PRACISE to avoid such a mess.

We have taken the point of view of creating once, reusing multiple times. So deleting a bot doesn’t necessarily delete the underlying components. We are looking into options on how we can do a cascade style delete for bots & its underlying components when they aren’t reused anywhere else in future releases.
In the individual tabs (events, processes, tasks) the components have a reusability indicator which when you click on it will provide information on which components it’s used in. Please see the “Reusability” section of the event help article.

• Step of “Branch on a condition” is taking the values from the immediate parent steps? Without input? Or it may take the row values from row at the time event is triggered?

Branch on condition step can use the row value(s) using standard expressions. It can also read values from a prior call process/return value (as discussed in earlier posts). We are adding support in future releases so other subsequent steps in the process can refer to values of previous steps in the same process wherever it makes sense.

• Step of “Branch on a condition” can be used like a data change event listener? Let s assume we add step right after step of call a Process which and where task will do change value in a row. Right after that we add new step for “Branch on a condition”. For this yes/no check expression, the expression like we used to use in workflow event, like [Co1].[_thisrow_after]<> [Co1].[_thisrow_before] kinds of expression would work? If this returns TRUE, do another bits and pieces. IF false, what is the best option with us to stop the whole operation. Just return value, STOP or something, which will not gonna be used anywhere though?

@Dan_Bahir can you help with this question?

• Based on the past experiences with action/workflow, our understanding is that action will only change the values in target row and field. But now, my understanding is that STEP will do add new row as well as update row value operation as well, which is bit confusing. What is the intention and notion behind that step is now capable of changing (update) row value as well as add new row?

I believe this is consistent with what happens in workflow rules/reports currently. @Dan_Bahir thoughts?

• I have BOT1 which is set to Table1. Another BOT2 is sitting on Table2. Also we have table 3.BOT1 will change the value in Table2. BOT2 will change the value in Table3. BOT can trigger another bot, so once BOT1 is fired, then BOT2 could be run as well. However, can we wrap those BOT1 and BOT2 into one BOT? In this single BOT, how can we set it up to run BOT2 inside single BOT? BOT2 will not have data change event listener… But need to be fired when Table 2 value is changed. Is it technically impossible to wrap to single app, but need to stay with 2 separate BOT?

I am not sure I understand your question here. Can you please rephrase or give me a concrete example with what you have created? Perhaps share some screen shots

• Hypothetically, BOT could run into infinite loop. The easiest case will be BOT is triggered by update row / field. This bot will do change the field value. Once this BOT is run, BOT will not be re-run otherwise, BOT will be keep updating row forever. BOT will not be re-triggered by data change event which is caused by themselves? I tested with simple scenario, but BOT only run once. I just wanted to know why it happens. (and infinite loop NOT happens)

Bots are designed to not have any recursive calls. The change has to be triggered by something outside of the bot i.e an app making a change or a change occurring due to the API being invoked.

• BOT is not able to change usersetting values, but is it on the roadmap?

Not currently. Can you provide a concrete use case?

• Once multiple BOT is prepared, then we don’t know which tasks, process are depending on other BOT etc. Need to get the relational maps to see visually the relationships. Ideally, we wish to see from task, process side that what BOT is associated with them. IF nothing, then we could delete easily when we need to clean up.

That’s a good input. We will explore options on how we can render such a graph.

1 Like

Hi @prithpal
Thank you very much for your time and detailed clarification. I added my further comment against your inline answers.

This is working as designed. See the explanation below:
These are the options for “Add or lookup process input?” that can be used in a task of type “Call Process”:
a) Add - In this case a new record will be created using the data you supply. If another record exists with the same primary key, that record will be updated and used.
b) Lookup - In this case the record if you supply the primary key then the data will be retrieved using the primary key. Any additional columns will be used to update the record.

I tested 4 different scenario and found out one difference between ADD/LOOKUP now.

Case 1) Add - Process input [ID] => [ID]
Case 2) Add - Process input [ID] => Uniqueid()
Case 3) Look Up - Process input [ID] => [ID]
Case 4) Look Up - Process input [ID] => Uniqueid()

Result
Case 1) Update existing row
Case 2) Add new row
Case 3) Update existing row
Case 4) Do nothing. Nothing to happen

when we pass uniqueid() expression with Lookup varb, then it will do nothing, as I suppse the BOT unable to find the exsitng row with uniqueid() which is kinds of makinse sense to me, but I could not come up with practical use cases for this logic. For me, still not clearly understandable whe we have two different verbs here, Add or Lookup. When and where each verb will be used.

Re-usability does have good benefits but understand that it adds some complexity. We have made some enhancements to the UI to indicate when components are being reused (for eg: if you go to the task page, we show where all the components are used. If you try to delete a task that is used by multiple processes you will have a prompt that lets you know that you are deleting a shared component. It seems like there are additional opportunities for improvement (in the bot interface) and will definitely explore those.

Awesome!

We have taken the point of view of creating once, reusing multiple times. So deleting a bot doesn’t necessarily delete the underlying components. We are looking into options on how we can do a cascade style delete for bots & its underlying components when they aren’t reused anywhere else in future releases.

Awesome!

In the individual tabs (events, processes, tasks) the components have a reusability indicator which when you click on it will provide information on which components it’s used in. Please see the “Reusability” section of the event help article .

Great!

Branch on condition step can use the row value(s) using standard expressions. It can also read values from a prior call process/return value (as discussed in earlier posts). We are adding support in future releases so other subsequent steps in the process can refer to values of previous steps in the same process wherever it makes sense.

Awesome!

@Dan_Bahir can you help with this question?

Great to have further clarifications about it.

I believe this is consistent with what happens in workflow rules/reports currently. @Dan_Bahir thoughts?

Definitely the step (call a process) wiht initial input alone with do add or update task which should be believed only TAKS could manipulate the values. Currently I see the step (call a process) arrangement is workings like a TASK (Change data) which is kinds of confusion, as again we believe the data manupilation could be done through TASK.

Bots are designed to not have any recursive calls. The change has to be triggered by something outside of the bot i.e an app making a change or a change occurring due to the API being invoked.

Based on your clarifications, I still believe there will be chance to see recursive calls. BOT is triggered by manual change in data. BOT runs a task to call the API to change the value in the same row. If bot is triggered by change data by API ,then BOT would re-run? Am I right? or missing something?

• BOT is not able to change usersetting values, but is it on the roadmap?

Not currently. Can you provide a concrete use case?

Okey, that is fine. We stay with our own current arrangement.

1 Like

Case 1) and Case 3) is what the ADD / LOOKUP is essentially the planned for “use cases” i.e with the ID field.

Case 2) is a side effect of exposing that capability and someone could use Uniqueid() as you pointed out. & Case 4) is behaving the way it should.

So to summarize Case 1) & Case 3) are the planned usage for this feature.

1 Like

You can have an IfElse that does something in the case of a true condition and nothing in the case of a false condition.

So you could define any number of step under the true condition.

If you would like to share what you are trying to achieve rather then how you are trying to implement it I could offer suggestion on how to implement it in the best way.

The data actions work in workflows in the same way that they work inside steps in a process. There are actions that add a row to a table and actions that update the current row. So I am not sure that I am understanding why you are saying that it behaves in this way.

The only thing that we added that allows you to either create a new row or use an existing one is the Call Process Step. That will allow you to call another process with an existing step if you provide the key for it or call the process with a new row that you create during the execution of the parent process.

I hope that clarifies the issue.

Hi @prithpal @Dan_Bahir
Thank you for additional clarifications which help us to understand how Automation is going to behaive as well as giving guide how we should set up particular automation for particular purpose, and we should “avoid” etc.

Understand passing process input [ID] === uniqueid() is sort of side effect, we user can add new row through this initial proess input operation which should not be a core of the usage here.

My point here was “Add new rows” was purely done throug the Appsheet Action. Add new row to another table using the column value of this row.

But I understand the same operation could be achieve just pure “process input” set ups.
For answers from @Dan_Bahir , now i understand we are able to leave the branched (conditional) branch brank out, set up no-step, which will do nothing (naturally).

The list of my quesions I raised not necessarily backed with the particular use cases for Automation. Before I goes into the actual and practicale use cases we can push to app users as new features, I just needed to understand correctly How Automation is going to be set up, as wel as what is poissible, what is impossible, how can we set up under the possible scenerios and combination of the components (event, task, step and process) This is where all the question from me is coming from.

We keep continuing testing and learning Automation and will get back if new questions come up.

Thank you again.

2 Likes