Is there a possibility to submit multiple approval user tasks to different approvers?
Summary: Matheus Anitelli is developing a workflow for data set approval where data stewards select necessary columns for submission. These columns will have different assigned approvers, and they seek a workflow where only assigned approvers approve their respective columns. George Cheung suggests a feasible workflow involving script and user tasks to track approvals or rejections, proposing that only rejected columns return for fixing while others proceed. Matheus Anitelli later adjusts the approach to generate provisional datasets tailored for each steward, using a multi-instance activity to manage these sub-processes, and seeks feedback on this new method.
Hey all,
I'm developing a workflow that has the following purpose:
Data stewards will select some columns that they deem necessary to add to a created data set for a specific purpose (such as... AI's use cases), and will submit the data set to this approval workflow. The data set will contain multiple columns coming from different tables, and with different approvers assigned to its columns. With that said, our idea is that the columns would be approved only by the assigned approvers and not by all stewards involved in this process. Is this feasible? If so, what would be the best approach to develop the workflow to achieve this goal?
Also, imagine a situation where we have 5 approvers involved in the data set approval process, but not all of them have approved their columns. 4 of them have approved, and only one rejected it. In our process, if an approver rejects the metadata of their columns, the columns would return to a step where someone responsible for fixing them would need to do it. So, my other question is: is it feasible to return to this point, only the rejected columns, and the approved ones proceed to the next phase? Or if one approver rejected it, the entire data set will go to the "fixing phase"?
Regards.
George Cheung
·3 months agoI think this workflow is feasible
Here are the steps I think you would need in the workflow - after the approval process starts on the dataset asset:
script task:
gather columns from dataset through relationApi
from columns gathered - find the approver (in format of collibra usernames) through responsbilityApi
combine approvers to a unique list - save globally through execution.setVariable
create map of approvers to columns - save globally through execution.setVariable
create map of approvers and empty results - save globally
creates parent comment for recording results - save parent comment id globally
multi instance sub process - iterates through the unique approvers list - gathers the approvals
user task: task assigned to approver with candidate user expression something like: user(${approverName})
task has options for approve or reject along with a comment box, and displays the columns the approver is approving
a timer boundary for a reminder email would be a good feature
script task: post submission
gathers the option selected by approver and records it to the global map of results
adds reply comment with approver name and result
script task - post approval process
after the multi instance has completed - evaluate the approval results
if there are no rejections
data set status changes and workflow ends
else if there is one rejection -
workflow routes to a user task for ‘fixing phase’,
variables are overwritten for approvers who rejected to approve again
exclusive gateway to determine result
path to end event if there are no rejections
path to route to user task for fixing
end event
user task - "Fixing Phase" -
a user task assigned to Data Steward to fix outside of the task
the assigned user can click on a Done button to mark task completed
after fixed - path back to the multi instance sub process to approvers (who rejected) for re-approval
Hope this helps.
Matheus Anitelli
OP3 months ago · EditedHey @George Cheung ,
Thank you for your comment.
We recently adjusted the approach for this workflow. Instead of generating separate user tasks for each Data Steward, we aim to simplify both the workflow execution and its maintenance by creating temporary, steward-specific datasets.
The workflow will first identify the Data Stewards responsible for the dataset columns. Based on that mapping, it will generate provisional datasets containing only the columns assigned to each respective Data Steward. This means that, rather than receiving the entire dataset and manually locating the columns that require approval, each Data Steward will receive a tailored dataset containing only the assets they are responsible for reviewing.
These provisional datasets exist solely for the approval process. Once a Data Steward completes the review and approval, the corresponding provisional dataset can be deleted, as it is no longer required.
My current idea is to leverage a multi-instance activity to create and manage these approval sub-processes. Each instance would handle the review cycle for a specific provisional dataset. Once all provisional datasets have been reviewed and approved, the original dataset would proceed to the publication stage.
One additional requirement driving this approach concerns how column ownership will be handled when multiple Data Stewards are assigned to different combinations of columns.
For example, if Column A is assigned to User1 and Column B is assigned to both User1 and User2, I believe this should result in the creation of two separate provisional datasets:
Dataset 1: Column A → User1
Dataset 2: Column B → User1 and User2
Even though User1 is involved in both approvals, I would prefer not to merge these into a single provisional dataset. The reason is that User2 is only responsible for Column B and has no responsibility for Column A. By creating provisional datasets based on the exact approval group for each set of columns, we can keep ownership and approval responsibilities clearly separated, avoid confusion for the reviewers, and prevent potentially complex situations where users are exposed to columns that are outside their scope of responsibility.
My goal is to keep the approval process as simple and deterministic as possible, ensuring that each reviewer receives only the columns relevant to them and that each approval decision can be clearly traced back to the responsible steward(s).
I would appreciate your thoughts on this approach, particularly regarding the use of a multi-instance implementation to manage these sub-processes.
George Cheung
·3 months agoHi
It sounds like this new approach is more complicated than the original from a design and implementation perspective.
Here is why it is more complicated:
The approval starts on the original data set asset - it will then need to create provisional assets containing the columns - then each respective approver will need to approve on that new provisional asset - this is multiple workflow definitions on multiple assets (original asset and new provisional data set) with multiple workflow instances (parent workflow for original dataset, and child workflow per provisional data set). Communication between the multiple workflow instances across multiple assets can be difficult.
if you are creating a new asset - and in the asset are the columns of the associated approver - just for each approver - and running the workflow on that new asset while starting it from a different dataset (different workflow instances) - then deleting it afterwards - then it sounds like the provisional asset itself was unnecessary step altogether.
Instead of creating a new asset and running a workflow on that new asset - and then communicating back and forth between the different workflow instances and assets - you can assign a single task to the approver on the original data set - and in the approver's task - you can display the columns that they are approving - if you want to further expand on it - you can add checkboxes for each column - and the user would need to manually select each one to confirm - if there is one unchecked then its considered a rejection (unless another approver has it checked in their approval task) and would need to be addressed during a fixing stage.
In the feedback earlier, that design was based on it running at the data set level - and has one task per unique approver. The reason why this step was in the first script task: create map of approvers to columns - save globally through execution.setVariable - this is so we can display these columns for the approver to see what they are approving and reducing tasks of the approver to minimize tasks assigned.
If you want to further track it in the workflow - you can create a parent comment on the original data set asset that has an approval table - where it shows each column and who signed off on it as each approver updates it.
Hope this helps.