I’m working on an SMS sending project, and I recently added a trigger.before to check for non-GSM characters when a user creates a new message template. I include the violating characters in the thrown error message, and it’s important for the user to be able to reference these characters.
The issue is that the error message disappears too quickly. It seems if you move your cursor over in time and stay hovered over the message that it won’t disappear, but that is sub-optimal.
Is there any way to
extend the time before an un-hovered error message goes away.
or
have the error message persist until the user manually dismisses it with the “X”
option 2 would be preferable, but option 1 will work.
Hi there, can you please clarify where the error message is dissappearing too quickly? Is it in a client application, or are your “users” logging into your 8base workspace?
We don’t have an option for tweaking the length of show time on workspace errors. I can let the design team know the complaint, as this is a unique use case of using the Workspace.
That said, could you potentially handle the invalid characters by inserting correct ones so that your user doesn’t receive errors?
No worries. Replacing the characters is kind of a unique problem in this context. The trigger automatically replaces any non-GSM quotes, apostrophes, and spaces. Using non-GSM characters such as emojis will make the SMS more expensive to send, but maybe that emoji is important to the team that designed the message, so I can’t automatically replace that, but I do want to make the user aware of that added cost. Also there are characters that look relatively normal but are non-GSM.
Another related idea – for the same reasons as above, I’ve included a boolean field ‘override’ which the user can set to true to push the message through with non-GSM characters present. It would be slightly cleaner if I could create an error/warning that has deny and accept buttons.
Again, this is probably a slightly fringe case. I might look into creating an app specifically for the users to input this kind of data. That would give me a lot more control over validation, correct?
You have complete control over the validation! You just have very limited/no control over customizing the UI of your 8base workspace.
To make a customized UI experience, I’d 100% encourage that you go the route of building an app for your users that let’s them manage their SMS messages! Otherwise, I’d take the approach of adding errors to the record itself (fields like falure: true/false and failure_message: 'Some message') that explain to the user why the message didn’t send, and if updated could be resent (or forced).