Switch User / BAR TAB integration

Had a call from client who said he started up a bar tab today and it kept popping up every time he used the tills. So he had to cash it off and manually tab up for the customer.

So I decided to think about this myself rather than ask, but upon changing things I got behaviour which was wrong.

Tutorials used were


The Switch user uses [:UserName] and bartab function closes it with the username too. So when a bartab is created and closed… all is good until you go to open a new ticket.

What I tried to do was add an action to the BarTabs to create an entity state of ‘BarTab’ when its set as a bar tab and for the Switch User to only bring up the order if ‘{ENTITY NAME:BarTab} is NULL’ but this doesn’t seem to work?

Can anyone spot where this wouldn’t work?



Have have a constraint on my switch user that it doesnt work if the ticket has my autoprint state of bar tab

Shouldnt it be on the open hold ticket rule? as it should only trigger to the stored order if its NOT a bar tab.

heres a screen shot of what ive added, but its not playing ball.

EDIT: I changed the Constraints so ‘{TICKET STATE:AUTOPRINT}’ but it still logs into the bar tab instead of a new ticket.

Woop, again I excel myself :smiley:

I just added to all rules in the Switch User Rules…

Execute Rule if Matches / Matches All - {TICKET STATE:AUTOPRINT} Not Matches Bar Tab

Works flawlessly :smiley:


1 Like

Thats how i did mine :slight_smile: sorry if i wasnt so clear before


Sorry to bump, but between this and the other question I had ive integrated the two and they don’t like eachother…

Can you see any problem here?

Edit, ive used all of these for the Rules… just showing an example

Edit, Ive just changed the rules to NOT MATCHES still wont switch or close


You cannot close a Ticket if it does not have an Entity Assignment, unless it has a Ticket Tag.

so you could add another action to the rule above that assigns a ticket tag of Switch User when you press your SU_Switch User Button

1 Like

Just to add, I’m assigning it to a table.

Scenario is, if I assign a ticket to a table then use switch user then itll log me back in showing the table I had just created.

I am assigning it to a ticket.

Ill check that rule you just said though… that may work


Ok I did that and then set it to only show if {TICKET TAG:Switch} is NULL

but its put me in a loop.

I don’t get it… surely if I didn’t want the table to show on switch, my original constraint should work?


Try using your entity table constraint but instead of being is. NULL You could use not matches and then add your table numbers separated by a pipe, for example

{ENTITY NAME:Table} not matches 1|2|3|4

Bit of a ball ache listing all your tables but see if that works, if it does theres probably a way to do it without listing them all

Try it with just one table number first to see if the constraint works, then create a ticket using that table number and see if the switch user now works

Or could you use { ENTITY } not equals or matches Table instead of using entity name?

Remove the Entity Constraint.

Put a Show Message Action in the Rule to see if it is firing and put {ENTITY NAME:Customers} (with ‘s’) and {ENTITY NAME:Customer} (no ‘s’) in the message.

I am also confused as to why you have an Action named SU_Switch User button in your Rule. What does it do? Is it calling the same Automation Command Name that the Rule is for? If so, you could case an infinite loop if your Rule Constraints are not carefully planned and met.

Tried it with just Table 1 and it still logs into the user and shows the table.

Tried with ENTITY not matches/equals and it does the same.

When I settle a ticket it opens the settled ticket and wont let me out of the screen till I press close, when I log back in it takes me to the settled ticket again, stuck loop. Happens on both instances above.


Rule is firing because it works with the bar tab constraint within the rule I have running works perfectly. The SU_Switch User Action is a log out action, I have changed the name to reflect this and avoid confusion.

Its only a small village pub, If I cant get this working then ill just scrap the Tables and use Bar Tab only. If they never had it they never knew it existed right?


I say that yet the bar tab isn’t working now…

I wonder if ive broken something in the process, might delete everything and start again.

EDIT: yes it does I just needed to close and reopen samba


Right, ok so the Rule is firing. Still put a show message action in there as I suggested to ensure you are reading the entity properly.

That was the point of my post - to see what is available to use as a Constraint, but you must remove the Entity Constraint first.

The Show Message Action is your #1 troubleshooting tool :wink:
The Rule Debugger is your #2 troubleshooting tool.

1 Like

ok will do now be right back!


So I did {ENTITY NAME:Table} and {ENTITY NAME:Tables} as a message. I then selected Table 1

On Log in it returned 1 and 1


Changed the constraints I was using to {ENTITY NAME:Tables} Not Matches 1 and its worked…

let me see if is null works…


So first of all, either the plural or non-plural version both work, which is expected. But it has been mentioned previously to prefer the plural version since it is theoretically faster. Use {ENTITY NAME:Tables} whenever possible.

Since your Table Names are in your case simply numeric, you could use this:

[=TN(’{ENTITY NAME:Tables}’)] Greater 0

You could also use, as @RickH mentioned, this:

{ENTITY NAME:Tables} Matches 1|2|3|4|5|6|7|8|9

The overall Rule should be set to Execute when Matches or Matches All

I still don’t understand this. Your Rule has 3 Actions:

SU_Switch User button
Close Ticket

It appears you have a Logout action in there as the 3rd action. If the 1st action is also a Logout action, then you need to place it after the Close Ticket action.

Maybe post a revised screenshot with your actions expanded. Also post screenshots of all the individual Action definitions being used in the Rule.

It was a mistake on my side, I had confused myself by not adding log out to the action so created a second rule.

1 of them has now been removed.