+5Hello all,
I have a small question, is there a possibility to trigger a small and simple process flow per record switch? When I switch record, I need it to do a request to retrieve some data to use in a custom component. To further simplify said custom component, and to further simplify our code, I would like to ask if it is possible to trigger this per record, so only the necessary data is retrieved.
Best answer by Arie V
We did do something else: the ‘Refresh table’ process action can be used as Start action in Universal since version 2026.1.10. Note that it only works for 2 types of refreshes:
Auto-refresh in combination with creative use of the Change detection logic might get you where you want to go. If the Auto-refresh triggers the Process flow, you should store the PK of the record on which the Process flow is being executed. Then in the Change detection logic you should check if the col_id of the selected record matches the one that was previously stored. If it matches, suppress the Auto-refresh. If it doesn’t match, perform the Auto-refresh and subsequent Process flow.
Note: if multiple users could be working with the same records, you might want to make it more robust by including the newly introduced session variable tsf_client_instance_id:
I don’t think this is possible without some unorthodox workaround, since there is no starting action based on a row change.
Perhaps you could do something with the default. I don’t know the source of the information. But if the information is not changed regularly you could set up a system flow to set up a table with the information you want to retrieve for all rows that runs every x minutes depending on how long it takes to execute and accurate the data needs to be. And then retrieve the information in the default, but this is depending on how frequent the data is changed.
If you have some more information on what you are trying to achieve then perhaps I or someone else on the community can help.
If you have some more information on what you are trying to achieve then perhaps I or someone else on the community can help.
As Erwin already stated, your goal would be helpful, but as for the workaround the layout may be a better option. As opposed to the default, it is also executed on simple record change without editing the record.
+5
If you have some more information on what you are trying to achieve then perhaps I or someone else on the community can help.
As Erwin already stated, your goal would be helpful, but as for the workaround the layout may be a better option. As opposed to the default, it is also executed on simple record change without editing the record.
My whole obstacle now is that, for every record that needs a custom component (a previewer that shows a technical drawing for instance) needs to do a call to a service, with data strung together in a view. That data in the view could be used in a process flow, instead of in said view. Then the process flow could execute the request to the service, removing the request from the custom component, thus simplifying the component and making it purely for its sole purpose: previewing.
So the TW part of our software does the request the component otherwise does, that can be done very well with a query and an http call in a process flow, but this is a per record request.
Then the retrieved data can be saved in a table. That can be used and sent to the component, so it only retrieves the data, doesn't know about any services other than the TW part of the software. So it only does what we want it to do: to preview stuff.
But this cannot be executed per record (yet). I would need to refresh, reload or switch details when I want to achieve this. This means that I need to do a very concious action if I want my preview data. But it should execute this request for the record I am on, as soon as I switch to the said record.
I hope this information is sufficient. If not, I would like to know what is not quite clear yet. Maybe I should add a little diagram of what I try to explain, if that would help.
+12
We did do something else: the ‘Refresh table’ process action can be used as Start action in Universal since version 2026.1.10. Note that it only works for 2 types of refreshes:
Auto-refresh in combination with creative use of the Change detection logic might get you where you want to go. If the Auto-refresh triggers the Process flow, you should store the PK of the record on which the Process flow is being executed. Then in the Change detection logic you should check if the col_id of the selected record matches the one that was previously stored. If it matches, suppress the Auto-refresh. If it doesn’t match, perform the Auto-refresh and subsequent Process flow.
Note: if multiple users could be working with the same records, you might want to make it more robust by including the newly introduced session variable tsf_client_instance_id:
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
