Subworkflow (Parent / Child) or plain field reference to instance

0

Hi Roman,
You can add a picker on the change form as a required field, which has a data source connected/created with all requests for which changes can be registered. picker will be able to store data in the ID#name format, which will be information for which workflow ID this change is registered, it can also be a link if you want, if you use the bps source. then in the main application you can add a sql grid field that will return all the change documents for which the ID (from the picker) is {wfd_id}


You can also use an action that will create your registered workflow, as a sub-flow (it will add an entry to the wfelements table in the wfd_wfdid column), then you will automatically see the related sub-flows on the right side of the main workflow.

Regards.

Hi Roman,

my solution would be similar to Karols. What I don't understand is the part:

"(this is because "everyone" can make a change request to a request - but should not have access to all requests [it is more about the fact that a request should be "improved" by other persons or departments after a closer look - but they originally do not have access to the original request]))."

As I understand it, you have a "source" / "original" request, which contains information which should not be accessible to everyone.
At the same time the users can add new requests to the "source" request. They could technical identify the request via a choose field with popupsearch mode to display more data.
What I don't get is, how should the users know in the first place, that there's a request to which they want to add a change?

Or is there some other list / view outside of WEBCON where the change requests are listed?

Best regards,
Daniel

Hi Karol
The suggestion with Instance ID from Parent is excellent, that's what I will do.
Thank you very much.

Hi Daniel

I can absolutely understand that you don't get it. 😁

The thing is, in our company (and that's why we also have to add an additional field "Requester" to almost every Webcon application / process that can be ≠ the author) sometimes the supervisor gets the order to start a process for an employee or vice versa.

For example, the manager gives an employee "A" the order to submit a request. A bit later, he gives an employee "B" the task of creating a change request for the original request.

Why he did not make the request himself from the beginning, well, that remains the secret of the business department.
I no longer argue with the business about whether requirements for processes are good/reasonable or not. (Unless they completely go beyond the limits of what is achievable).

Best regards,
Roman