Notify parent

RE: Notify parent

David Jimenez — Thu, 10 Jul 2025 15:43:36 GMT

But when the process finishes, the user is "redirectd" to the first one and the page is refreshed.

RE: Notify parent

Flávio Miranda — Thu, 10 Jul 2025 15:37:00 GMT

I used this approach, but this navigates the user away from the page.

The other solution would be implementing the form in the same page as the list ( but if the client accepts this solution then that will not happen)

RE: Notify parent

David Jimenez — Wed, 09 Jul 2025 21:08:51 GMT

Try using a startProcessLink and using an start process form for editing the interfaces.

RE: Notify parent

Flávio Miranda — Wed, 09 Jul 2025 15:25:28 GMT

[quote userid="50400" url="~/discussions/f/general/39418/notify-parent/149741"]processing [/quote]

The purpose of the parent interface is to have a list of processes in a table, and when the user clicks the edit button the edit form interface will be displayed like a one page app, upon completion/cancellation of edition then the parent interface shows again the list.

In this case the actions will be chained together and attended by the user that triggered the edit button.

In this flow:

List of Process >> Edit Process >> Back to List and repeat

I would use a record action, but then there would be a page navigation to a new page within the same tab. Would there be a work around that would allow me display/hide an interface on the parent when the user submits a form?

BTW thanks for the time spent explaining

RE: Notify parent

Mike Schmitt — Wed, 09 Jul 2025 13:41:32 GMT

What are you wanting your interface's behavior to do and under what conditions?

Generally if you use a!startProcess() it's either to run some synchronous but unattended processing (have some node(s) do some chores for you with no further user interaction needed in-process) and pass any result data / files / status back to the calling interface via the "onSuccess" parameter.

Or alternatively, it can launch something that'll be user-facing (i.e. a task) which will be assigned to them and they can complete at their whim, but from the point-of-view of the launching interface, this will be inherently asynchronous (regardless of what setting you use in a!startProcess()), and the calling interface will only be able to get any info that happens up until when the task is assigned, at least without doing considerably more work (querying running instances, etc).