He more than likely just updated it for v5. Previously it was archived in v4 and its slightly harder to browse those tutorials now considering the categories are hidden on first navigation.
You didn’t show the rule but if you have historic orders where name used to be customer name and not primary (entity name) is now number it wouldn’t work.
Interesting to use program setting over a entity custom field for last ticket…
You would need to either update program sting names to numbers OR change the rule so it searches for entity data:name rather than entity name.
What @JTRTech is saying is about what you mentioned:
The Rules search and set data for a Customer based on {ENTITY NAME:Customers} or [:EntityName]. So whenever you see one of those variables being used in the Rules, you might need to change that to use instead:
{ENTITY DATA:Customers:Phone}
But to be sure, show a screenshot of your Customer Entity Type configuration of the Custom Data Fields, and a screenshot of one of the Customers to see what type of data is stored in each field.
Ok, so your Primary Field is “Phone”. That means {ENTITY NAME:Customers} or [:EntityName] used in the Rules will show you the Customer Phone Number, and {ENTITY DATA:Customers:Name} can be used to display the Custom Data field called “Name” which contains the Customer Name.
I think the issue is that your Entity Type Name is not “Customers”… it is " Customers E T ". So in your Rules, anywhere you see this:
I think no Ticket Number has ever been stored to the Entity because the Rules were not working as expected to be able to store the Ticket Number in the Entity State.
Try creating a Ticket for a Customer and Settle it. This is when the Ticket Id is stored in the Entity’s State named CLastTicketId.
Then select the same Customer again, and try to Load Last Ticket.
I’m pretty sure it is because it has been changed from primary field of name to number.
Obviously the program settings based on entity name (when was ‘customer name’) won’t match what entity name now is which is customer number. These are not backdateadble and either need amending or adjusting for.
If the other topics are for same system it wouldn’t be entity name but data:name or manual change system settings from name to number.
That was where my comment about storing ‘last ticket’ as another custom entity field over using program settings came in.
Believe options are either use entity data:name would be option one HOWEVER this was changed to number for primary field due to name duplicates which will cause issues if using name, Alternativly manual updating stored program value names to customer number in place of name, or MY recommendation would be a ‘from this point forward’ solution of switching to an extra entity data field of last ticket id and use entity data rather than program setting and bite the bullet of from this point forward - that is dependent on number of values stored over time to update vs companies of this point forward inconvenience.