LOL you went from almost getting it and me showing you the method… to switching completely to a different method and not getting it at all.
Please dont take this the wrong way but what is happening here is basic knowledge mistakes. You lack the basic understanding and are attempting more advanced setup. It will benefit you tremendously to visit the tutorials portion of the forum and practice the advanced tutorials. It wont solve your current need immediately but it will get you familiar so you can solve your own custom setups.
Laying a little groundwork and doing some homework first will help you solve your needs faster, maybe not right now but I promise you will need more configuration later and will run into similar issues later if you dont spend some time with tutorials and allow yourself to learn the system.
You wont like my advice but my advice is to stop doing your current configuration and practice some tutorials first.
The switch to tag isnt going to be the cause of the issue with the ask questions - its going to be the addition of return to order screen and change of cancel to cancel orders rather than it being a second ask question like it was before (at a guess).
Will guess it will be the lack of definement in the ask question values as i mentioned before causing confusion.
OK, have discussed setup with Johnson_O directly as would have taken long time to solve with back and forth screenshots etc as was some confusion with route to take. Have evaluated his desired workflow and for anyone follwoing there was not one key aspect which solved the solution and was easier to rebuild the kiosk workflow than adjust the existing settings using a sequence of ask questions and exacute automation commands.
However I stumbled on a couple of points/issues which I wanted to bring up. @emre
This was on V4 and have not had chance to try and replecate on V5 to see if still an issue however, one aspect discused and now implimented was switching the kiosk from using entities to using ticket tags for customer info. That bit is fine but we did this by using [?Prompt] fields in the customer detail ticket tags and a couple of points on this.
First one was is (and if not can we look at an option to go in V5) to make these type of fields *required ?
I found a good post on definging the [?Prompt] expression with mask, type of keyboard etc but no required option that I could see…
Second point was while trying to work a system for making these fields required I may have found a bug (in V4 i know but if not raised may still be in V5)
To make the fields required I first tried making an exacute automation command with a constraint which checked that all the ticket tags had values - this initially required a delay to allow time for the tags to be applied before checking them, this automation command fired an ask question prompt saying all fields are required and another exacute automation command to return you to the Customer Details rule with the updae ticket tag actions [?Prompts]
(Additioanlly which I thought was quite tidy was to constrain the update tag actions to check that its corasponding tag was blank meaning when going back to the ?prompt only the fields which were left empty are shown)
Either way, I got an error (sorry dont have the exact quote) which in short as far as I could tell was because there was two [?Prompt] expressions in the same workflow with the same name.
While I can understand if it was in the same rule even if they were seperated by an automation command loop with a delay the error still ocoured.
My solution was to move the tag validation to post order when submit/pay was selected and then reopen the customer detail prompts which solved the error.
If the error report is required I know the exact sequence of events causing it and can replecate if needed. (again not checked V5 yet and will do if I get some time tonight)
Another though which came up is one which I have mentioned before about ‘IS NOT’ mapping.
In this setup there were many departments and plan for multiple terminals.
The configeration I was helping with was for the customer kiosk.
As a customer kiosk there are very limited buttons/abilities and its pretty much a completely seperate workflow.
The buttons and rules were all mapped to the KIOSK department however when it comes to making any changes to his setup for the other departments every rule and a command etc will need mapping to each department other than KIOSK and I think he has 4-5 departments.
What I am getting at is would the ability to map IS NOTsomething that is ideal for this solution?
The other departments are likely to have similar workflow as will be staff operated however the majority of future configeration will be that side and mapping every rule multiple departments would be so mush simpler if you coudl just say !=KIOSK, we have the ability to say any state of a kind (Status=)?
Just a thought…
By design this is allowed so you can combine one input for two or more actions. If they share same name then it will prompt ONCE for that input and it will insert it into all actions that share it.
How do you propose Is Not mapping work? I mean mapping is a relation… so what relation would Is Not be? Emre would have to completely redesign how mapping works. It might be slightly more work (Not really) to just map it correctly but that means you have less evaluations and its much less system overhead. To implement IS Not it would require much more extensive evaluations and cause more memory use, system resources, etc. just for mapping… is that worth that?
So look at mapping… how would Is Not fit in with this?
Like Emre has said before he can implement anything but sometimes there are other things we should consider. In this case you would take it from simple relationships to a complex system of evaluation expressions.
Dont think I explained that well enough, they were not duplicates in the same rule it was if a ?prompt was in the same flow ie:
Rule A [command name=customerdetails → Update Ticket Tag [?Customer Name] → last action automation command validate)
Rule B (command name =validate) constraints of TICKET TAG:Customer Name}==‘’ → execute automation command customerdetails
Rule B returns you to the update ticket tags rule if the ticket tags are empty.
Thanks for explaining the way mapping is recorded in the database, I understand what your saying
Yes, it returns the customer to the Customer Details Rule if a field was empty = tag is blank.
If I move the validation step to a separate rule ‘string’/‘flow’ it works fine.
The error stated there is already a field [?xxxxx (depending on the first ?prompt) in the… cant remember the term it used.
Thats because you did. It looped it back with same rule but was already submitted.
Sometimes crashes are good it tells us when you broke something. Sometimes they indicate bugs… but in this case its a good crash it tells us we configured something wrong.
Intentionally allow empty values doesn’t sound like a solution for any value required.
I have read that post but am not sure how to have an open length mask but be required…
