TAOM Integrations
Your tools stay. Your information comes together.
Transformation does not happen in one application. Processes live in process platforms, requirements in the delivery system, knowledge in the collaboration tool, execution in the ERP. TAOM connects these views instead of opening yet another silo. It does not take the place of these systems but takes care of the relationships between the information they hold.
The starting point
Software is rarely what’s missing
Most organisations have powerful platforms. The problem is that information is spread across them – and nobody owns the context in between.
Why it matters
The process is the shared point of reference
A requirement from a project – once without and once with context.
What the result looks like
An issue and a page, generated from the model
Not a marketing screenshot but a template with demo content – it is about the layout and where each field comes from.
The Jira issue carries the TAOM ID as a fixed key, plus epic reference, component, WRICEF labels and the sub-issues. The Confluence page is created as a readable document: running text at the core, key figures and status compact in the page info on the right. The mapping of process to epic, phase to story and step to task holds both together.
View template → · Read the article →
Template with demo content – it describes how the result is structured. Jira and Confluence are products of Atlassian; SAP is a trademark of SAP SE.
Maturity
Integration grows with you – and we say where we stand
Nobody needs full automation on day one. Five levels, and the honest status for each.
Five levels – and where TAOM stands today
Which side leads for which detail is defined per field.
The areas
What works today – and what doesn’t
Delivery platforms · Jira
The process element holds the details needed for implementation:
- Issue type
- Priority and status
- Component and version
- Responsibility
- Requirement
- Development object (WRICEF)
- Process reference
The shapes use the official, unmodified Jira icons and status colours. The base address of your own instance is set in the settings – only then do the links lead to the right target.
What works: The model produces an epic, stories per phase and issues per step. The run happens after human approval, writes key and address back and reconciles on every subsequent run instead of creating duplicates. Return path – in production today: If someone changes the status in Jira, our own Atlassian app reports it back to the model. Which side leads for which detail is defined per field – what the model leads cannot be overwritten from outside.
From Enterprise. This applies to both directions, outbound and return. An actual connection to Jira requires a dedicated environment and the customer’s Atlassian licences. It is not part of the Demo, Process Studio Modeller, Webuser or Webuser Pro tiers and is defined in the Enterprise contract.
Knowledge platforms · Confluence
Process steps can be linked to the related documentation – work instructions, functional and technical specifications, decisions, meeting outcomes, policies.
What works: A model produces a page tree with process pages and specifications, each with ID, level, status and links – reconciled on every run. Return path – in production today: If a text section is changed in Confluence, our own Atlassian app reports it back to the model, within the fields that Confluence leads.
From Enterprise. As with Jira, for both directions: dedicated environment, own Atlassian licences, defined in the Enterprise contract.
Microsoft 365 · SharePoint and OneDrive
This is the most advanced integration: via Microsoft Graph, TAOM reads a configured folder recursively, fetches every .bpmn or .xml file and creates a workspace from each file. The credentials are stored on the server; all calls run via the server.
Direction: currently into TAOM, not back.
Channels · Microsoft Teams and Slack
With the Team add-on licence, messages from the model go to your own channels in Microsoft Teams or Slack – for example a failed test run. The channels are set up in the customer account; more under collaboration.
Direction: out of TAOM, as a message.
ERP · SAP and others
Process steps carry the application context: which application supports the step, and which ERP component and functions belong to it.
Behind this is a dedicated reference work with over 2,400 documented mappings of process step to component and function. Every row carries its source – it is searched, nothing is invented.
What doesn’t work yet: technical access to running ERP systems.
Process platforms · SAP Signavio and others
Models can be exchanged in both directions via BPMN 2.0. An existing repository therefore does not have to be abandoned – TAOM can run alongside it as an enrichment and transformation layer.
Basis: file exchange, not a coupling of the tools.
Architecture, automation, AI platforms
Structured context is the prerequisite for linking capabilities, applications and requirements with the architecture, triggering flows or supplying agents on third-party platforms with enterprise context.
The interfaces exist. The integration itself is defined per customer – direction, scope and reconciliation behaviour depend on the target platform and the project.
The goal
Every thing should know where it belongs
What matters is that the mapping is preserved in a transfer: a requirement stays with its process, a development object with its requirement, a system with the steps it supports. If these links are preserved, transformation becomes traceable and manageable – that is the whole point of the exercise.
View the Digital Twin → · Tooling in the framework → · Discuss interfaces →
API and extensibility
Not just connectable. Addressable too.
Enterprise context does not only deliver value inside TAOM. Through an application programming interface, your own applications, integration services and automations can access processes, details and functions – without anyone having to work in Process Studio for it.
Workspaces and models
Create, read, change, retrieve versions. Plus phases, metadata, groups of several diagrams and the provenance seal.
Enrichment
Start a run, query the status, fetch the result – also for a single element instead of the whole model.
Attachments
Upload, list, retrieve and remove documents – bound to the element they belong to.
Agents
Directory of agents, style profile, library, plus request and result of a run.
Users and licence
Sign-in, account, licence status – the basis for a third-party application acting on behalf of an authorised user.
Presence
Who is currently working on a model. This lets you reflect collaboration outside the interface too.
The interface lives under the namespace taom/v1 and is versioned – a new version does not silently replace the old one.
Get started
Start with the system that hurts right now
Don’t connect everything at once. Take the system that makes the difference in your project and connect it first. The rest follows step by step.
What ends up in Jira and Confluence stays findable
Issue numbers and page links sit on the process step – and are therefore searchable across all models. Which steps don’t have a Jira issue yet? Where is the specification missing?
And if the target system is your own?
Jira and Confluence are two routes – not the only ones. Processes, attributes and models can be retrieved via the interface and taken over into your own systems.