Process Modeller (BPMN 2.0)
Visual BPMN 2.0 process design with simulation. Workflow steps reference content actions, role assignments, and business rules natively. Process versions deploy with audit trail.
Process Automation
OpenText Process Automation Implementation Services
Most BPM platforms struggle when the process is content-heavy — claims, KYC, grievance, onboarding, dispute resolution. Pega and Appian compose the workflow, then case content lives in SharePoint or email, and the case loses 5-10 days to a folder. OpenText Process Automation (formerly AppWorks) is the content-native BPM platform. BCS implements the dynamic case management model so the case content, workflow, business rules, and analytics live on one platform.
Cases close faster
CASE TURNAROUND TIME
Case content, workflow, and rules on one platform — the 5-10 days lost to documents sitting in inboxes is reclaimed.
One platform
CONTENT-NATIVE BPM
Process, case, rules, and forms run against the same Extended ECM or Documentum repository. No bridge code between BPM and ECM.
Developer Aviator
LOW-CODE AI ASSISTANT
Developer Aviator generates process apps from natural-language descriptions. Citizen developers ship case applications faster.
Architecture
Five Layers Of OpenText Process Automation
A content-native BPM platform built for case management at enterprise scale
Pega and Appian are excellent BPM platforms. They are also bridge-dependent when the process is content-heavy — case files, supporting documents, signed records all live in a separate ECM and travel by reference, not by integration.
OpenText Process Automation lives on the same OpenText repository as Extended ECM and Documentum. The case workspace, the BPMN process, the business rules, the forms, and the case content share one runtime. The integration boundary disappears.
01 - Process Modeller
BPMN 2.0 process composition
Visual BPMN 2.0 process design with simulation. Workflow steps reference content actions, role assignments, and business rules natively against the same runtime.
02 - Dynamic Case Management
Flexible workspaces for knowledge work
Cases combine structured steps with unstructured artefacts — documents, emails, decisions, supporting evidence — on one workspace per case. Knowledge workers operate the case file as one record.
03 - Business Rules Engine
Decision tables for repeatable decisions
Rule sets and decision tables externalised from process logic. Business analysts adjust eligibility, routing, and exception rules without touching the BPMN model.
04 - Forms And Templates
Drag-and-drop form designer
Forms, document templates, and case views designed in the platform's low-code surface. Forms bind to case attributes; documents render in workspace context.
05 - Developer Aviator AI
Low-code app generation
Developer Aviator generates process applications from natural-language descriptions. Citizen developers describe the case workflow; Aviator emits the starting BPMN model, forms, and rules.
Why Process Automation
The Four Scenarios That Move Process Automation From Consideration To Programme
Process Automation programmes get budget when one of four operational realities forces the decision.
01 - Long-running cases stalling
Cases spend more time in inboxes than in the workflow
Claims, KYC, onboarding, dispute resolution cases lose days at a time sitting in someone's inbox or a shared mailbox. SLA breaches drive customer escalations. The COO needs the case-handling estate to move from email-and-spreadsheet to a managed workflow.
02 - BPM platform content gap
The chosen BPM platform cannot host the case content
Pega or Appian is deployed for the workflow but case documents live in SharePoint, network drives, or an ECM behind an integration. Knowledge workers context-switch between the BPM UI and the document store. The integration overhead consumes value the BPM platform was supposed to deliver.
03 - Content-centric process emergence
A new process is being designed and it is content-heavy from day one
A new regulatory regime, a new product launch, or an M&A workflow surfaces a process that is documents-first. Generic BPM is the wrong starting point; content-native BPM ships the case workspace and document handling together.
04 - OpenText estate expansion
Extended ECM or Documentum is in production and BPM is the next workstream
The content estate is on OpenText. The next obvious step is to bring case management onto the same platform so the case workflow runs against the same governed content store, with the same identity model and the same audit trail.
Business Impact
Who Benefits From The Process Automation Implementation, And Through Which Operational Lever?
Process Automation lands across operations, IT, and compliance differently. Each accordion names the specific lever.
COOCase turnaround, SLA recovery
For the COO, the question is whether the case-handling estate can run on SLAs instead of escalation chains. Process Automation moves case management onto a managed workflow with case content on the same record.
- Cases close on the workflow rather than in inboxes. SLA dashboards become real.
- Knowledge workers see the full case record in one workspace — documents, decisions, history.
- Business rules adjust without developer cycles when policy changes.
CIOBPM platform consolidation, content-native architecture
For the CIO, Process Automation replaces the bridge between BPM and ECM. One platform hosts the workflow and the content; integration code retires.
- BPM and content services consolidate onto OpenText — one platform rather than two with a bridge.
- Developer Aviator low-code surface reduces the backlog for process app delivery.
- Native integration to Extended ECM and Documentum means case content lives where governance lives.
CFOOperating cost, case productivity
For the CFO, case-handling productivity is a labour cost line. Process Automation moves productivity by eliminating context-switch overhead and surfacing SLA-breach risk earlier.
- Knowledge worker productivity gains compound across thousands of cases per month.
- Exception handling becomes a routed workflow rather than a daily email triage.
- Audit and compliance retrieval against case files becomes a single workspace lookup.
Head of Business ProcessProcess design, continuous improvement
For the Process CoE, Process Automation is the runtime for the redesigned process. BPMN models execute against the case content. Continuous improvement happens by adjusting rules, forms, and steps without re-platforming.
- BPMN 2.0 process design with simulation runs against the real case data.
- Business rules externalised — policy adjustments do not need a release.
- Case-level analytics surface bottlenecks, rework loops, and SLA risk.
Chief Compliance OfficerCase audit, regulator retrieval
For Compliance, the case file is the audit artefact. Process Automation keeps every step, every document, every decision on the case workspace with audit trail integrity.
- The case workspace IS the audit artefact — documents, decisions, signatures all on one record.
- Legal hold places the case beyond disposition with one workspace flag.
- Regulator retrieval against historical cases takes minutes, not days of cross-system search.
CHROHR case management
For the CHRO, HR cases (grievance, ER, accommodation, regulatory inquiry) carry sensitive content and tight retention rules. Process Automation handles them on the same record model.
- Sensitive HR cases run on workspaces with access governance from Anugal.
- Case retention enforced by document class — sensitive cases purge on schedule.
- Case history retrievable for regulatory or employment-tribunal inquiry.
Chief Data OfficerProcess analytics, case data semantics
For the CDO, case data feeds process analytics. Process Automation surfaces case metadata into Datasphere alongside operational data for cross-process insight.
- Case attributes feed Datasphere semantic models — case KPIs sit alongside operational KPIs.
- Aviator generates case-level summaries and trend analyses against the governed case store.
- Process mining tools read case events from Process Automation directly.
Chief Strategy OfficerM&A case integration, scaled rollout
For Strategy, acquired entities arrive with their own case-handling practices. Process Automation absorbs the cases onto the master workflow with controlled migration of in-flight cases.
- Acquired entities' case backlogs migrate into the master Process Automation workspace pattern.
- Case-handling SLAs harmonise across the consolidated organisation.
- Legacy case-handling systems retire via Information Archive once cases close.
Capabilities
Components Of OpenText Process Automation
Five product components organised across process, case management, rules, forms, and AI.
Dynamic Case Management
Case workspaces combine structured steps with unstructured documents, emails, decisions, and supporting evidence. The case workspace is the case record.
Business Rules Engine
Decision tables and rule sets externalised from process logic. Business analysts adjust eligibility, routing, and exception rules without code changes.
Forms And Templates
Drag-and-drop form designer for case views and data entry. Forms bind to case attributes. Document templates merge case data into outgoing communications.
Developer Aviator (AI)
Low-code app generation from natural-language descriptions. Aviator emits starting BPMN models, forms, and rules from a process description; developers refine.
Native ECM Integration
Process Automation runs against the same OpenText repository as Extended ECM and Documentum. Case documents live in the workspace; no bridge integration code.
External System Connectors
Pre-built connectors to SAP, Salesforce, Microsoft 365, ServiceNow. Process steps reach external systems through the connectors with no bespoke development.
How BCS Implements This
The Six Workstreams — What BCS Owns, What The Client Owns, When Each Runs
A Process Automation programme typically runs 14-22 weeks per initial process domain. BCS sequences six workstreams.
01Weeks 1-4
Process Discovery And Case Analysis
The target processes are catalogued. Case volumes, SLA targets, current pain points, document types, and external system touchpoints are mapped. The first process for implementation is selected.
BCS owns: discovery tooling, process catalogue, prioritisation framework. Client owns: business-process owners, SLA targets, case-volume data.
02Weeks 3-8
BPMN Process Design
BPMN 2.0 process model for the selected process. Steps, role assignments, decision points, exception paths, and timing rules are designed and simulated against historical case data.
BCS owns: BPMN modelling, simulation runs, design baseline. Client owns: business-process owner sign-off on the design.
03Weeks 5-12
Case Workspace And Forms
Case workspace template, document type catalogue, and forms designed in the platform low-code surface. Document templates for outgoing communications configured. Aviator-assisted generation accelerates first-pass forms.
BCS owns: workspace design, forms and templates, Aviator generation refinement. Client owns: business-user testing of the workspace and forms.
04Weeks 8-14
Business Rules And Integrations
Decision tables and rule sets configured for eligibility, routing, exception handling. External system connectors (SAP, Salesforce, Microsoft 365) activated for the specific data flows the process requires.
BCS owns: rule configuration, connector setup, integration testing. Client owns: business analyst sign-off on rule logic.
05Weeks 12-18
Anugal Access And Pilot
Anugal IGA configured for case workspace access — particularly important for sensitive cases (HR, regulatory, dispute). Pilot runs with a controlled case volume. SLA adherence and exception patterns measured.
BCS owns: Anugal access policies, pilot orchestration, SLA measurement. Client owns: pilot case-handler enablement and sign-off.
06Weeks 16-22
Production Cutover And Adoption
Production cutover for the first process. Aviator activation for case summarisation and document drafting. Adoption metrics tracked. Next-process roadmap scoped against pilot learnings.
BCS owns: cutover orchestration, Aviator activation, adoption measurement. Client owns: enablement programme, change management.
About BCS
BCS — The Agentic System Integrator For Content
Content programmes that ship as an operating model, not an event
BCS implements Process Automation as part of the broader OpenText practice. The Process Automation team carries content-centric BPM experience — the difference between a workflow that completes on time and a workflow that loses 5 days to a folder.
The agentic system integrator model means three operating platforms travel with every Process Automation programme. Each plays a role named below.
Anugal
Case access governanceIdentity governance over case workspace permissions. Sensitive cases (HR, regulatory, dispute) carry tight access certification — Anugal extends governance over case workspaces alongside the broader content estate.
deKorvai
Master data validationCase attributes that bind to master data (vendor, customer, employee) are validated before configuration. Dirty master data becomes dirty case classification; deKorvai catches it upstream.
Symphony
Process cutover orchestrationCutover orchestration for the new process. In-flight cases on the legacy system migrate or run to completion under controlled rules. Symphony manages the cutover window with rollback path.
Recent Updates
What Has Changed In Process Automation In 2026?
Three updates shaping the Process Automation conversation in 2026.
AppWorks rebranded as OpenText Process Automation
The August 2025 OpenText product rebrand simplified the name to OpenText Process Automation. The underlying technical name AppWorks Platform remains in developer documentation. In-flight programmes are unaffected.
Source: OpenText rebrand announcementDeveloper Aviator low-code app generation
Developer Aviator generates process applications from natural-language descriptions. Citizen developers describe the case workflow; Aviator emits the starting BPMN model, forms, and rules. Developers refine the output.
Source: OpenText Developer Aviator4/5 on Gartner Peer Insights for low-code platforms
OpenText Process Automation carries a 4/5 rating on Gartner Peer Insights for Enterprise Low-Code Application Platforms across 50+ reviews. Vertical strength: financial services, insurance, healthcare, public sector.
Source: Gartner Peer InsightsFrequently Asked Questions
The five questions that decide the Process Automation programme.
How does Process Automation compare to Pega or Appian?
Pega and Appian are excellent BPM platforms. Process Automation differentiates on the content side: it runs on the same OpenText repository as Extended ECM and Documentum, so case documents live in the case workspace natively. For content-heavy processes (claims, KYC, onboarding, dispute, grievance) this removes the integration overhead. For pure transactional workflow with minimal content, Pega or Appian may be the better fit.
Do we need Extended ECM or Documentum to use Process Automation?
Not strictly required — Process Automation can run standalone with its own content store. However, the platform's strongest fit is when an OpenText repository (Extended ECM, Documentum, or Content Hub) is already in production or planned. The case content then lives with the rest of the governed content estate.
Can business users build process apps with Aviator?
Developer Aviator generates the starting BPMN model, forms, and rules from a natural-language process description. Business users review and refine. Production deployment typically requires a developer review — Aviator is a starter, not an unattended generator. The combination shrinks the design phase significantly.
How does this interact with our existing process mining tools?
Signavio, Celonis, and other process mining tools can read case events from Process Automation. The case data model exposes events for mining, so the existing process improvement programme continues to operate against the data Process Automation generates.
What is the commercial engagement model?
Most Process Automation engagements run as fixed-milestone delivery for the first process domain (14-22 weeks), with discovery priced separately. The team typically includes a programme lead with OpenText AppWorks/BPM experience, two to three process consultants, a business analyst for rule design, an identity engineer running Anugal, and a cutover lead.
Scope The Process Automation Implementation In 30 Minutes
BCS runs a 30-minute readiness session covering the target process inventory, the case-handling pain pattern, the OpenText repository state, the integration scope, and the Developer Aviator activation sequence.
30-minute discovery session*