In the old workflow architecture, we had two roles: the main person responsible and the user. The main person responsible started the process and the user received an email to fill out a form.
Technically speaking, we have a main document and an included document. We send the main document from the frontend to the workflow and this starts the process. In the start event, a task document is generated from the included document, on which the data generated by the user is then stored. In the meantime, the task document is checked by the main person responsible and only at the end is the task document merged with the main document. In this way, we were able to ensure that the data contained in the task document is only visible in the main document during the review and at the completion.
With the new architecture, we thought that we would then only work in the main document and only at the end did we realize that we could no longer guarantee that the intermediate steps such as filling in, checking and correcting should not be present in the main document.
Is there a way that the intermediate steps of the data are not visible in the main document without a high level modeling approach?
Should we use a different modeling method instead of working with included documents, if so, which one would you recommend?
Hi @steve-tagged-cache
@peter-smooth-cursor is the real expert when it comes to Workflows but as you’ve asked about Modeling here’s a few points from a Modeler’s perspective.
- Workflows recommends Attribute Based Access Control (ABAC)
This was true both for the old and the new Workflows architecture. It’s not possible for me to model a single Document Model and also
A Developer can achieve this using ABAC to control the access of this data based on things like the Document Status or the User who is currently logged in.
Using ABAC would then allow you to achieve your goal “without a high level modeling approach”.
- Workflows supports Relationships
In 2023.06 there is a delegate that you can use to create a Relationship Link between two Documents with known docRefs.
${createRelationshipLinkDelegate}
Further delegates and support have been added in 2024.06.
This means that if the “main” and “included” documents were separate you could link them automatically in your Workflows process. This could help ensure the separation of the data that you require. However you should be aware that this leads to:
- A “higher level modeling approach”
- Knock-on effect if you then use the data from these 2 Documents later (you might then need to model a CDM)
The with-workflows workspace that comes with the 2024.06 installer has an example of creating and linking two documents in a workflow.
Thank you for your very quick reply.
ABAC sounds great, can you give me an example of how I can show and hide data from an included document?
Hi @peter-smooth-cursor, do you see any other possibilities here?
Hi @steve-tagged-cache
unfortuately, I don’t have the skills to be able to provide you with an example for ABAC. I’ve passed it on to my more technically gifted colleagues though 
.
Hi @steve-tagged-cache,
One clarifying question regarding this: does this mean you duplicate the included document, and you call this duplicated document the task document?
If that’s the case, you COULD do the same in the new architecture, although the merging back of the task document into your main document may need a different implementation.
While that may be a technical option, it sounds like this is a good use case for relationships (as Malcolm suggested) to keep these documents separate and avoid duplicating them.
It should be possible to implement ABAC rules that grant the “main person responsible” access to the linked task document only if that task document is in state “in review” or “at completion”. This should, in turn, fulfill your use case that they can only see the info in those states. I’m not sure if you need custom code in the frontend to handle the fact that, sometimes, you can see the linked document, and sometimes you cannot.
I think this access rule is the crux of your use case so I’d like someone from UAA to verify my statements. @tuan-stable-gale could you have a look?
Best,
Peter
Hi,
thank you for your reply
Yes, that is correct. We duplicate and the duplicate is the task document.
What do you mean by saying that we can do the same in the new architecture because we will then only have one document reference in the process?
Hi @steve-tagged-cache,
Here’s my understanding of your situation:
- You have a model
Main_DM which has an include of a model Include_DM.
- You start a process by passing in a
Main_DM, let’s say Main_DM/42.
- You have custom code attached to the BPMN start node (or somewhere close to start).
- Here, you read the content of the include from
Main_DM/42 and duplicate it to create a new document of Include_DM for the purpose of the process, let’s say Include_DM/17.
- The user tasks only modify
Include_DM/17.
- At certain points in your process, you read
Include_DM/17 and push its changes back to Main_DM/42. This is only time Main_DM/42 is changed by the process.
If this is the case, you can do the same in the new architecture. All you need are the two document references, which you have: Main_DM/42 would be passed on process start and Include_DM/17 is created within the process. So you have both.
I’m probably missing something because I don’t understand why
In general, you can have any number of docRefs in a process. Either by passing them on process start or by creating them within the process.
Best,
Peter
Hi,
thank you very much for your support. I will prepare your solutions and present them to my team. I still hope to get the example with the ABAC “how I can show and hide data from an included document”.
Greetings
Steve
Hello @steve-tagged-cache
In order to “show” and “hide” you can use Property Authorization.
You need to clarify these factors:
- The resource type which you have in your hand. In this case a A12 Document (which includes another A12 Document, properly you can have it from an Event listener which fired by A12).
- Define Property Authorization in Authorization JSON file:
- Define Property Permission and Property Right using Property Authorization from UAA. *
- The path using dot notation which point to field you want to control access.
- call hasUAAPropertyPermission via annotation.
This will allow you to make sure the visibility and changes of your data are correct in the level of Field/Properties.
For more reference:article from Property Permission questions in there you can fine a bit more code how user is using (did) or in our documentation GetA12 Login