Login Credentials Email Template "ResetLink"?

Hi Alan, 

It's a template parameter. It's included in that template as an example of how parameters work. If you are making other edits to the template, you could certainly hardcode the URL into the template instead.

Also, am I reading correctly that emails are only going to be sent once every five minutes? That seems like an inordinate amount of time to wait for a lost password reset. 

Also, am I reading correctly that emails are only going to be sent once every five minutes? That seems like an inordinate amount of time to wait for a lost password reset. 

All HTML templates are managed on a queue process, including login credentials, order confirmations, and mobile tickets. The polling frequency of the queue can be changed in the settings of the Tessitura Processing Service, and we do currently recommend setting this at 5 minutes. I do take your point about waiting for a Forgot Login email and I will raise it with our teams. 

I am shameless about setting my queue frequency to 1 minute. But I still think that's a bandaid over the problem that some emails just need to be sent synchronously (like they used to be) -- password resets for sure, and any acknowledgement triggered from the client. You should be able to talk to a customer over the phone and have them receive an order confirmation before you hang up.

I view immediate delivery of Forgot Login emails essential. I know if no online e-commerce site I regularly do business with as a consumer where those do not arrive almost immediately. It’s what patrons will be expecting (and rightfully so). 

I already voted these up, but seconded/thirded/whatever.  Forgot Login should be as near instant as possible for the customer experience.  Same as Nick said regarding client side e-mails when you are talking to to someone.  Web orders?  Eh, I can take a few minutes on those.  Patrons do not necessarily need the confirmation within 30 seconds.  A minute or two is fine there.

I am a patient man; 5 minutes is fine for most things with me.  But 5 minutes does seem like a long time in this internet heavy/instant response world.  And we know that patrons love to push things that we think should be "good enough".

More upvote for near-instantaneous password reset, especially if the password reset in the Contact Details > Logins > Forgot Login goes in the same up-to-five-minutes queue because tying up staff in the wait-time as well as the patron double ugh.  

It's actually worse than 5 minutes (or 1 min, which is what we set it to). If you have ever load tested TPS and pushed like 500 order emails into the queue, a user who requests a forgot password as they are processed is at the back of that queue.  They can be the configuration value + all the time it takes TPS to process what is ahead of them.

This is really, really crappy during a large onsale when a nervous patron has something in their cart and your seat timer is set to 11 mins and it takes 8 mins to get a reset password email.

As a relative newbie to Tessitura world, it's interesting to learn about this queue process and its limitations. On other software platforms I'm more familiar with, this would be solved with prioritized queues, where urgent, user-requested emails like password resets go into a high-priority, continuously running queue that would only get delayed by more than a few seconds due to an unusually high volume in the queue. Less sensitive emails like receipts would go into a lower-priority queue that could get processed every few minutes or as able when the high-priority queue is idle. I'm a little unclear why any kind of polling interval would be necessary though, as the queues I'm familiar with are continuously running processes that are throughput limited only by the number simultaneous queue workers, each running on a separate thread. Is the polling to help control server load? I would think a continuously running process would usually be less resource-intensive, since it's handling requests as they come in, not bunching them up in batches every few minutes.

Michael--here are some results from when I tested TPS a few months back.

I inserted 400 concurrent password resets into the queue table.
The first one was sent 18 seconds later. The last one came across 7+ mins later:
queue time: 2021-03-24 10:11:05.077
process time: 2021-03-24 10:18:28.420

These forgot password resets should really be sent concurrently and not queued up.

Thanks so much Patrick (and everyone else) for the suggestion. I included this thread in the enhancement request that I logged based on this discussion. We appreciate knowing how important this is to everyone, and our developers will review it.

Has there been any movement on this? By the time my lost password email arrives, I've moved on to other things.