Return the chosen option from a message using tsf_send_message

Hi Marieke,

The message options are indeed used in process flows only and currently do not function when using tsf_send_message.

Can you describe a concrete example of how you’d want this to work?

A message via tsf_send_message can be sent from basically any logic concept (Default, Layout, even a Badge) and the code flow at that location will continue immediately or abort; it will not wait for the user input.

In order to react to the user input, we’d need to process the chosen message option somewhere.

Would this be an entirely new logic concept, or would the tsf_send_message trigger the start of a process flow?

Doesn't program code wait for the tsf_send_message to complete?

Is it possible to start a process flow by displaying a message?

The logic execution continues after the tsf_send_message is posted, the program does not wait for it to be shown to the user. 

Starting a process flow after displaying a message sounds like a pretty cool idea, but it becomes a bit tricky since the other action might not yet have completed.

For instance, you can post a tsf_send_message while editing from Default logic or from Badge logic. The user would not be ready to accept a new process flow at that time.

Is there a specific scenario where you’d like to see this functionality?

Client has entered some data and starts saving. During commit (trigger) a check is made. If the check says, it is not OK to continue anyway, then a message is displayed telling what the situation is and asking if the client wants to continue anyhow. Or not. Input from the client is needed.

Thank you for this example.

In this scenario, I’d advise to make the status persistent. Either at the record itself or a case relating to it. E.g. two checkboxes which are false by default:

• situation_confirmation_required 
• situation_confirmed

During the commit, the situation_confirmation_required flag can be set to true when confirmation is required.

A process flow should be in place to check this flag after the record has been saved. If true, the process flow can then present the user with the desired question and update the situation_confirmed flag accordingly based on the response.

Any follow-up logic should only be activated when situation_confirmation_required is false or when situation_confirmation_required is true and situation_confirmed is also true.

This makes the process a bit more robust. If the user is somehow forced to exit the user interface when the question is presented, the confirmation will remain pending for this case. For instance, when a client device loses power, when connectivity issues occur or when the application itself is experiencing downtime.

A case with pending confirmation can be highlighted to the user in their dossiers. The process flow asking for confirmation can be restarted for the user at any point in time. The user can also be offered the option to defer the confirmation to a later point in time. Furthermore, this status can be monitored by administrators and inspected by support staff.

If the logic execution itself were placed ‘on hold’ indefinitely while waiting for user input, we’d end up with an uncommitted transaction that would block interaction with the rest of the system. It would be quite challenging from a technical point of view to pick up where you left off.

I hope this provides some ideas on how to implement these scenarios.

Note that I’m certainly not indifferent to the idea of starting an ad-hoc process flow, for instance to present a question to the user. This can be very valuable in case-management scenarios. This could rely on tsf_send_message or perhaps a new concept to support passing on variables more effectively.

Thank you for this elaborate explanation. I will give it a try.

Hi @Marieke,

Can you provide us with any updates regarding this topic as a result of Anne's feedback?

Unfortunately, we have not received a response to our request for feedback. We therefore assume that the idea has already resolved itself or is no longer relevant.

Updated idea status Needs feedback → Closed