In my Pages app, I have an Inline list which opens up to a New Screen for that item.
In the New Screen I have 3 Choice components, each with 3 options of Dislike, Like and Love.
Dislike Like Love
Dislike Like Love
Dislike Like Love
Each choice writes to their own USC.
What Id like to do is add 3 news columns which are incremented on based on the choice chosen.
If user selects Dislike for Choice 1
Choice 1 - Dislike Choice 1 - Like Choice 1 - Love
I can currently do it via Custom Action with a ton of IF AND Combos (I believe I need 27 different combinations due to 3 questions and 3 answers) with various Increment Actions based on the Combo.
However, I am looking to see if there are any more creative options out there as building 27 different branches would take a lot of time!
I already tried using 3 buttons with an Increment Action but 1. The user can just keep pressing the button and 2. The button doesnt “highlight” if chosen so the state looks exactly the same if clicked”, so I dont think a button or Inline list would work for me.
Currently, if a User selects Dislike for the Taste Choice Component, it currently writes to a USC. But, I also have a Button that runs the above Custom Action, which only Increments Taste if Like or Loved is chosen. Same for Value and Quality.
What I’d rather have is if Dislike is chosen, it Increments my Dislike/Taste column. Same goes for if Liked or Loved is chosen, it Increments those respective column. This way, I know how many of each choices are being chosen.
However, I also have other choice components for Value and Quality as well. Therefore, it appears to me that I have to have numerous IF AND conditions in my Custom Action to ensure the correct columns are Incremented based on all the different combinations. Maybe I am overthinking it lol.
1 solution I thought of was to use a Button for each Choice Component to Increment the respective columns (and hiding the rest until the prior Choice is chosen). Only problem is that it now consumes 3 updates vs 1. I was hoping to avoid that.
Okay, one thing that immediately jumps out at me is that you have 3 separate increment actions in each of your conditional branches, which is going to count as 3 updates.
Given that they are all operating on the same row in the same table, surely you could consolidate each of those into a single action?
That would significantly reduce the number of updates.
Give me some time to digest and think about the larger problem. I dare say we can help you simplify that quite a bit.
Hows its currently setup (3 Increment actions), I actually tested this and it only resulted in only 1 update per submission!
This is a Pages project
Users are not signed in
Once they hit submit they cannot go back and update their choice
Once a user hits Submit, it updates a boolean to show “Reviewed” and I have a condition on the Show New Screen to only allow if Reviewed is not checked, preventing them from reviewing it multiple times in a single session.
The Rating Submit action uses a single Set Column Values action:
And each of the Taste/Value/Quality groups requires 3 additional columns:
The 2nd line in the above needs to be modified for each of Loves & Dislikes:
let inc = p2 === 2 ? 1 : 0;
and for Dislikes:
let inc = p2 === 3 ? 1 : 0;
And obviously the p1 and p2 values need to be adjusted for each column.
Let me know how it works out.
Side note to @Jeff_Hager
Column 1 returns 1 if input is 1, otherwise 0
Column 2 returns 1 if input is 2, otherwise 0
Column 3 returns 1 if input is 3, otherwise 0
I played around a bit with various combinations of mod(), ceiling(), trunc(), etc, but wasn’t able to land on something that actually worked. But I feel it should be doable. What do you think?
oh, I should add. The reason an if-then-else column isn’t suitable here is because we want to take the return value and add that to the pre-existing value (in the same formula). So whilst it would be simple to first do an if-then-else and follow that with a math column, the challenge is to come up with a single column solution
Interesting, I wouldn’t expect that.
Were you testing over and over again as the same anonymous user?
And were you testing in the builder, or published App?
The most realistic test I think would be with the published App, just reloading the page should be enough to clear the user specific values (I believe), so you could test over and over again that way.
Sometimes with these sorts of things the behaviour in the builder can be a bit flakey, but it works fine in the published App.
It should do, have you tried it?
But why bother with that if you’re only expecting a single set of ratings from each user? It’s an extra update that you don’t need to do.
Also, keep in mind that the default state for all users will be null values in those columns, so if that doesn’t work then the solution is broken
The first 3 columns use the Lookup + Single Value method to generate an auto-incrementing RowIndex.
SeedDate : that should be a date somewhere in the middle of the first month that you want start collecting data. The exact date doesn’t matter, just somewhere around the middle of the month is fine. I used the Text to Date plugin column for that one.
Date: this uses both the RowIndex and SeedDate to calculate a date for each row, incrementing by one month at a time. The formula for this one is a bit of a doozy, and comes from Jeff, not from me:
Do you want to break down the count of reviews by Restaurant, or do you just need a total count across all Restaurants per month? (or do you need both?)
If you need to breakdown by Restaurant, then yeah - that solution wont work at all.
Whilst it’s complicated, it’s nice because it doesn’t cost you any extra rows.
Anyway, before we head down that path, you need to answer the question above
Yes I would just need a rollup for each individual restaurant on how many reviews they received each month. Given that each review costs updates, I’m interested in putting caps on the # they can receive in a given month.
Also throwing around the idea of giving them unlimited surveys and just pricing the plan around the “average” if the above cant be implemented or costs too many new rows.
I initially had a dedicated survey table where all of this would be super easy, but Id chew through my 25k rows quite quickly. This way I really have zero row consumption, just updates that are scalable