Why this action is not working properly? When the condition is not met, it does not execute the [Else].
BSS
does the action run in the conditional scenario?
If you are referring to when the proper data is there? Yes, it does, but it appears to go to that screen whether data is there or not.
We would need to see a screenshot of the data related to the conditions.
In your case what happens if the condition is not met? Nothing? It goes to the New Bills tab regardless?
Maybe the first conditions are met so it wonāt fall to the else.
1 Like
As you requested.
Since you are running the action from a button Iām not sure you are connected to the correct row in your table.
I suspect you are only connected to the first row in that table.
If you ran the action from the list itself then it would probably work as expected.
I was a little lost in the video so maybe someone with a fresh pair of eyes might spot something I couldnāt.
1 Like
Hmm first why are you using is included in?
I would use āIf Paid inf is Unpaid and Status is Unapprovedā
Since paid and unpaid are clearly two different values you shouldnāt use is included in.
PS: āis Included inā checks if your value is included in the check which in both cases is true (Approved is included in Unapproved and Paid is included in Unpaid).
After watching again I think you need to change to Paid inf is āPaidā and status is āunapprovedā like Michael said
I will do that and show you what happens.
In my video I did say table when I should have said form. Sorry about that.
Do the words āUnpaidā and āUnapprovedā have to be placed in the condition the same as it is in the table?
But there seems to be a bug in the Action condition.
Just to make sure we arenāt getting off trackā¦make sure your conditions make the case exactly. Capitalise the the letters in your conditions to match exactly how they are written in the table. Just glancing at your videos quickly, Iām seeing proper case in the data, but you have conditions with either all uppercase or all lowercase. āAā is not the same āaā for example.
Jeff, I have checked everything and I am following this rule exactly, and that action is still not working properly. However, I created a test table with just the āPaid Infā and āStatus Fieldā and the Action worked properly for that row. But why is it that this condition in the Action cannot look into a row of data and find the conditioned data? I hope I donāt have to give up on this part of the app. I want to believe that it can work but I am losing hope on this feature.
Iād have to sit down and study your videos again. You are flipping through screens pretty quick, so I didnāt quite follow the full flow in the brief time I had to look.
I guess for starters I would add 3 text components to the screen that contains the button that calls your action, and point them to your RowID, Paid, and Status columns to understand which row and values your action is actually using.
Jeff, I will redo it later tonight and slow down slightly.
Here is a longer version of my problem:
Thank you for taking the time to make another video. Much appreciated. I think that helped clarify some things for me.
I think it goes back to what a few of us have mentioned previously. That button and action is only looking at one specific row in the table and we are trying to determine which row it is. Most likely itās the first row as that is the row that the screen is probably attached to.
I think where you may or may not be mistaken is that you might be thinking that an action will look at all rows in a table. That is not the case. It only works with the row that current screen is linked to.
What I was asked for previously was for you to add text components to this screen below to determine which row you are viewing. You could also do the same thing by clicking the data preview button in the bottom left corner of the builder screen. This will show you which row the screen is attached to, and which row the action will ultimately look at.
If all my assumptions are true and your action is only looking at the first row of the table, then I think a quick fix could be to apply a filter to your home tab screen to filter the screen to the first row that is Unpaid and Unapproved. That would allow your actions to run appropriately, however Iām not quite sure if there will be unintended consequences if the filter canāt find any rows that are Unpaid and Unapproved. In that case, itās possible that that certain components, such as your button could become invisible.
Another alternative is to create a query column in your table that looks for any rows in the same table that are Unpaid and Unapproved. This would actually be a much better solution because you could then change your action to simply check if the query is empty or not as the query itself is already checking for Unpaid and Unapproved. The query result would be on all rows, so your screen, and subsequently the action, would always be connected to a row that can check if that query is empty or not. Even better, you could probably put that query in the user table, and directly check it from the user profile (which is globally accessible) when setting up your action. The reason for putting it in the user table is because there will most likely be less rows in the user table, so less overhead from a query running multiple times.
Hopefully that gets you on the right path.
3 Likes
Jeff, first I want to thank you for your time and effort in helping me solve this problem. The program I used to develop my accounting software performs this action much differently because it can look into the entire database and not at the first row. But thatās not the case here and I will learn to use the Query feature more often. I hope I did not consume too much of your time last night, but you came through for me and I appreciate it. Thanks again.
Benjamin
1 Like