Setting an object at the process model level

There are several ways to approach this, and the best option depends on how your ARIS environment was implemented and which components/licenses you have available—for example, whether you have an API license.

From your description, it's still not completely clear what the exact task or limitation is. In general, there are many ways to integrate process and risk information and keep risk data synchronized with an external system.

If you have the ARIS API, you can implement the integration externally in almost any way—for example, with a custom application, integration script, middleware, or even an AI-based service. The external system can identify the existing risk object by its Risk ID and update the required attributes while keeping the same ARIS object definition.

If API access is not available, a very common approach is file-based integration. For example, the ERP/GRC system exports a file in an agreed format to a shared folder on a schedule, and an ARIS report/script reads this file, finds the corresponding risk objects by their external Risk ID, and updates the required attributes.

So I would first clarify what you want to achieve: whether the issue is reusing the same Risk definition at the process level instead of the task level, or keeping Risk attributes synchronized with the external system.

Hello Alexander,

Thank you for your reply. 

We have an API integration to keep the risk attributes in sync with our external system.

My objective is to have a way to use a risk object at the model level instead of having to tag it at each task in the process. So if a model has 50 tasks and the risk could occur or does occur at each task, the team wants to add it the model once so that it is noted as a process/model level risk.

Does this help?

Hi Beth,

I would use almost the same approach as I described in your glossary thread.

At the process level, I would create a Function Allocation Diagram (FAD) assigned to the process object and use that diagram to associate the relevant risks with the process.

Quite often, unlike glossary terms, risks may be maintained at more than one level of the process hierarchy. For example, a general fraud risk could be linked at L2, meaning that it is considered relevant for all subordinate L3 processes. More specific risks could then be linked on the FAD of an individual L3 process, meaning that they apply to the process as a whole rather than to one particular task.

So in practice, the FAD becomes a kind of semantic placeholder for process-level information such as risks, controls, KRIs, glossary terms, process owner, governing documents, systems, and other related objects.

Hi Alexander,

What if we don't use FAD at all. We use the Enterprise BPMN collaboration diagram for our end to end process mapping. The teams have also NOT created any VADs as there are over 300 processes already and more coming - trying to keep a VAD updated with all of these is not viable.

Hi Beth,

I can only recommend what I have seen work well in practice.

As I mentioned above, technically you can place additional objects directly on the BPMN model itself, for example, outside or below the pool. But I would consider this a poor practice. The Enterprise BPMN Collaboration Diagram is already quite a specific model type, and systematically placing unrelated or semantically unconnected repository objects on it can create governance and maintenance problems later. I also wouldn't recommend solving this through attributes.

I actually do not see the number of processes as a reason not to use a VACD or another architecture model. We have projects where the number of processes approaches 1,000. In such cases, the architecture model becomes even more useful because it gives you a structured way to manage the repository. It doesn't have to be a VACD. Depending on the methodology, it could be a Structure Model, Function Tree, or another model type. The important point is that you have an architectural layer that defines the process structure.

Using a structural model gives several advantages. For example, you can use it to manage governance information such as process lifecycle/status, ownership, or modeling progress. It also becomes an integration point between the process architecture and other repository content—risks, controls, KRIs, glossary objects, governing documents, etc.

It is usually the basis for integrating processes with each other through interfaces. Without an architectural model, I'd be interested in understanding how you currently manage relationships between your 300+ end-to-end processes. The same applies to integration with the organizational structure.

And this becomes even more important once you start using reports or scripts. Without an architectural model that defines the process hierarchy and relationships, it becomes much harder to reliably generate SOPs, job descriptions, process registers, risk registers, or similar outputs.

Of course, I do not know the full context of your project — what your objectives are, what resources you have available, what the required deliverables are, etc. It may be absolutely valid that the goal is simply “model it, implement it, and forget it.” I often see SAP-related repositories built this way, and if that is the actual objective of the project, then that is perfectly fine.