Hello,
whilst I’ve been working with CE, I’ve been wondering whether I can also use A12 to create a sort of process map?
As I understand it, a workspace always corresponds to a self-contained process. I haven’t yet come across a way to map different processes as a single map at a higher level. Is this possible with A12, or do you ultimately have to refer to the individual workspaces?
Thanks for your replies!
Hello,
it is unclear to me what you mean by process map.
An A12 Workspace openable in the SME is a collection of files containing models, user roles and data.
Related to processes we have the Workflows component, with which you can define process steps performed by humans and machines and how they are linked.
~ Patrick
Hello Patrick,
from an administrative perspective, I’m looking at an overview of the processes shown. In other words, I have a home page with various clusters, each of which breaks down different processes.
A specific example might be: the HR cluster, which includes processes such as holiday requests, business trips, requests for further training. All these items are defined as separate workspaces, as they have different process owners, logics, etc.
Perhaps I’m looking at this too analytically or overcomplicating things.
Thanks and best regards
Sebastian
Hello Sebastian,
You can define an overview like that using a Content Model, which can link to the different forms (Form Model) a user needs to fill with data (Document Model) to start a process.
Using the App Model you can define the application layout and display e.g. list of these filled forms (overview model) depending on the role/workspace a user belongs has (see Authorization and UAA).
For complicated processes with side effect you can use the Workflows Component, however this can be some effort and might not be needed for simple application forms.
Please take a look at all available models for more details.
~ Patrick
The assumption I would drop is “a workspace always corresponds to a self-contained process”, because a Workspace is a modeling-time container only. It is the folder structure that the SME, the Preview Application and the Workspace Converter expect (A12 Modeling Workspace). At runtime there is no workspace boundary. The deployed application loads the models located under import/models, and an existing Workspace can be imported into a project (Importing a Workspace). Therefore, one Workspace per process owner and one overview across all processes is not a contradiction.
For the map itself, on top of what Patrick already described: the clickable entries are Interactive Tiles in a Content Model, whereby each tile’s click event navigates into the module of the respective process (Content Modeling → Interactive Tile). Modules, regions and layout come from the Application Model (Application Modeling). Which clusters a user sees is not part of the map but role-based (Authorization).
Whether the map is a Content Model or a Dashboard region depends on what a single tile has to show. A Content Model is presentation content: free layout, text, images, tiles that navigate. The Dashboard layout arranges views as tiles, so it is the option if a tile itself has to render live data through an engine, for example the open holiday requests of that process, at the price of one view and its models per tile (Dashboard). Both can be combined, with the Content Model as the map and one module per cluster below it.
Two caveats when you merge the Workspaces into one application:
Important: model ids are global per application, not per Workspace. If the HR holiday Workspace and the business trip Workspace both contain a Document Model with the id Applicant, one of them wins after the merge and the other process silently references the wrong model. Therefore, I would recommend a per-process id prefix (hr_holiday_Applicant, hr_trip_Applicant) before the second Workspace exists, because renaming ids later means touching every Form, Overview, Relationship and App Model that references them.
Note: the map is content, not a generated view of the processes. A12 provides no “process map” mechanism by default, so nothing derives the tiles from the existing processes. A new process appears in the map if and only if someone adds a tile to the Content Model. A removed process keeps its tile until someone deletes it. If the map has to be maintained by the process owners themselves, this is the part that will drift.
The alternative is one deployed application per process plus a plain link page in front of them. It costs a deployment, user and role setup per process, and a cross-process overview list becomes impossible, but the process owners stay fully independent. From my point of view this is only worth it if the processes have to be released independently.
Small reminder because your topic is tagged 2025.06: the links above point to 2026.06, because that is where I checked the wording.
Thank you very much for the very detailed answers; they’ve really helped me understand the subject better.
I have one final question regarding the interaction between the process and the final deployment: Can I deploy just one workspace, or can I deploy multiple workspaces that are then available via a single A12 instance?
The deployment unit is the application, not the Workspace, because a Workspace is a modeling-time container only. Multiple Workspaces run in a single A12 instance if and only if their models are merged into one application, for example under import/models in the Project Template. The server reads the models at startup, so a restart is necessary after models were added.
Important: after the merge there is no Workspace boundary left, so the id collision from above applies to the deployment as well. If the holiday Workspace and the business trip Workspace both contain a Document Model with the id Applicant, they end up in one model set, whereby one of them wins. Therefore, the per-process prefix has to exist before the second Workspace is deployed.
Hint: with 2026.06 the server requires the runtime representation of the models, not the Workspace models. They are generated by the Workspace Converter, so the conversion belongs into the build of every process Workspace you merge.