IT service operations
Connector with OREA ITSM or an external ITSM: connect communication and operational context with service work.
The OREA Platform
In developmentOne operating layerfor connected work.
OREA Systems is being designed to connect communication, workflow, service-management, and operational systems around a shared model of context, policy, ownership, and controlled execution.
Explore OREA ITSMThe platform idea
Connect. Orchestrate. Manage.
Three connected ideas guide the product architecture: bring work into context, coordinate what happens next, and keep a clear destination for the work.
Connect
Bring communication channels, workflow platforms, and operational systems into defined integration paths.
Orchestrate
Carry context, policy, decisions, approvals, and actions across the workflow.
Manage
Provide service-management capability through OREA ITSM, or coordinate with an external system of record through OREA Connector.
OREA ITSM is not required for every Connector deployment. The platform direction supports both an OREA-native service destination and existing service or operational systems.
Architecture in layers
Different systems. A connected model of work.
The platform direction connects source interactions to service and operational destinations through explicit integration and orchestration boundaries.
Sources / channels
Where work can begin
- Microsoft Teams
- Contact center
- Web / API
- Operational events
OREA Connector
Integration and orchestration direction
- Capture
- Normalize
- Context
- Policy
- Orchestration
- Integration
Service / workflow destinations
Where work is managed or acted on
- OREA ITSM
- Jira Service Management
- ServiceNow
- BMC Helix / Remedy
- Operational services
Across the layers
- Identity
- Ownership
- Approval
- Audit-oriented history
- Security boundaries
These layers describe intended relationships, not a completed platform. Sources and destinations include development work and planned integrations; their current statuses are listed below.
OREA Connector
The integration and orchestration layer.
Connector is designed to carry work between interaction sources and operational systems, preserving the context that makes each next step meaningful.
Its vendor-neutral direction keeps integration boundaries explicit, so a workflow can coordinate with the systems an organization uses.
Capture and preserve context
Connect interaction sources, normalize events, and retain the relationship between the original interaction and ongoing work.
Coordinate the next step
Apply policy, support approvals, route work, and initiate controlled external actions through defined integration paths.
Keep connected work aligned
Synchronize relevant workflow information and retain operational history across participating systems.
OREA ITSM
The OREA-native service-management layer.
ITSM is being developed as a native place to manage service work within the broader platform, with a service record at the center of the experience.
It is an optional service-management destination. Connector can also support environments that retain external ITSM or workflow systems.
Organize service work
Bring incidents and service requests into service records with clear ownership, queues, and responsible next steps.
Keep decisions and conversation together
Connect communication continuity, approvals, concurrence, and workflow history to the work they concern.
Make the service context useful
Relate knowledge and operational visibility to service work so teams can understand the record and its progress.
Two product roles
Built together.
Useful for different reasons.
Connector and ITSM have distinct responsibilities within a shared platform direction.
Connector provides the integration and orchestration direction for work across systems, including environments that retain an external ITSM or workflow platform.
ITSM provides an OREA-native service-management destination for organizations that want service records and workflows within OREA. It is not required for every Connector deployment.
OREA Platform
Shared context, policy, and ownership
OREA Connector
- Integration
- Orchestration
- External systems
OREA ITSM
- Service records
- Service workflows
- Native workspace
Both products are in development.
Shared context
The context should move with the work.
An interaction is more useful when its people, decisions, records, and outcomes remain connected. OREA is being designed to preserve those relationships across system boundaries.
Shared reference point
Work in context
Each relationship helps explain the work, its destination, and the next responsible action.
- Source interaction
- Where the work began.
- Requester
- Who needs an answer or outcome.
- Identity
- Which person or system is involved.
- Service record
- The relevant service-management context.
- Workflow
- The path and decisions around the work.
- Ownership
- Who is responsible for the next step.
- Routing decision
- Why work moves to a destination.
- Approval / concurrence
- The review associated with a decision.
- External action
- What a connected system is asked to do.
- Notification
- Which participants need an update.
- Operational history
- What happened and what remains unresolved.
This is a product concept, not an internal data model or a claim that every relationship is implemented.
From interaction to outcome
A shared path through connected work.
The platform workflow brings intake, decisions, execution, and communication into one understandable sequence.
Capture
Work begins through a communication channel, API, or operational event.
Normalize
Represent different inputs through consistent platform concepts.
Understand context
Associate people, records, ownership, and relevant system context.
Apply policy
Determine routing, review, approval, and permitted next steps.
Orchestrate
Coordinate activity across connected systems.
Manage / act
Create or update service work, or initiate an approved operational action.
Communicate
Keep relevant participants informed.
Record
Preserve useful operational history.
The sequence describes intended behavior. It does not establish that every stage is fully implemented for every integration or deployment.
One workflow · Multiple systems
The work can cross systems. Its context should stay connected.
An email or Teams interaction could enter through Connector, reach the appropriate service destination, and keep the resulting decisions and updates associated with the original work.
The destination may be an existing ITSM platform or OREA ITSM. The shared direction is to coordinate context and policy without assuming that every record belongs in OREA.
This is an illustrative path, not a live integration, customer implementation, or promise of end-to-end availability.
Email or Teams
Source interaction
OREA Connector
Capture and normalize
Context + policy
Identify the destination and permitted next steps
Service destination
Choose the appropriate destination for the workflow.
- External ITSM
- OREA ITSM
Alternative destinations; OREA ITSM is optional.
Approval / technician / operational action
Review, service work, or a controlled action
Requester update
Communication connected to the work
Recorded history
Retain decisions and outcomes
System-of-record philosophy
Connect systems without pretending every system should become OREA.
When Connector is used with an existing ITSM or workflow product, that platform may remain the authoritative system of record.
The integration should respect where service work is owned. OREA is designed to carry context between systems while preserving a clear distinction between orchestration and record authority.
OREA ITSM offers a native service-management direction where it fits the organization. Adopting Connector does not require that choice.
A defined role across systems
OREA can focus on the connected workflow.
- Interaction capture and context
- Orchestration and communication
- Integration and synchronization
- Workflow history
The existing platform can retain authority over its service records, ownership, and service workflow.
Integration direction
Defined pathways. Visible status.
Communication channels, service platforms, and operational sources have different roles and different stages of development.
These statuses describe current development work and product direction, not production availability or vendor partnerships.
Email / Microsoft Graph
In developmentMicrosoft Teams
In developmentJira Service Management
Development integrationCisco Finesse
PlannedServiceNow
PlannedBMC Helix / Remedy
PlannedWeb / API
Platform direction
Orchestration & human control
Automate where appropriate. Keep people in the loop where necessary.
Policy should guide routing, approvals, concurrence, and controlled actions. Human review and triage remain part of the platform direction wherever context or authorization needs attention.
An uncertain external outcome needs an explicit next step. Review and reconciliation are intended to establish what happened before another action is attempted.
Automation is being designed around permitted scope and accountable decisions.
- Work
- Context
- Policy
- Auto-action permitted?
Yes
Controlled action
Proceed within the permitted scope.
No / uncertain
Human review
Resolve context, approval, or outcome questions.
Action / return / triage
The chosen path determines the next responsible step.
Record
Keep the decision and outcome in operational history.
Communication continuity
Communication should be part of the record, not a separate universe.
The platform direction connects conversations to service and operational work, so the next participant can understand what happened and what needs attention.
Connector is intended to provide the integration pathway. OREA ITSM may provide the service record, or an external ITSM platform may remain the destination and authoritative system.
Intake
An email, Teams interaction, or requester reply brings new information into the workflow.
Context
The interaction is associated with a service record and relevant technician context, including downstream operational work.
Update
Service updates and requester notifications preserve a connection to the work, so replies can continue the same conversation.
Identity and ownership
Every uncertain item should have an owned path.
The platform direction connects who requested the work, who owns it now, and who is responsible for what happens next.
Uncertainty should lead to a responsible owner.
When identity, routing, or an outcome needs clarification, the intended path is owned review or triage with enough context for a person or team to decide the next step.
Recognize the person across systems
Requester and user identity should remain associated with the work. Connected-system identity mapping and explicit external identities should make those relationships understandable.
Make responsibility visible
Assignment, queue and team ownership, and the responsible next action should travel with the workflow as work moves between people and systems.
Respect organizational boundaries
Identity and ownership decisions should respect tenant and organization boundaries, with access considered in the context of the connected system.
Reliability principles
Retain the work. Make the outcome clear.
These architectural principles guide platform development, from the first interaction through review, action, and recovery. They describe design intent, not performance guarantees.
- Durable work
- Important work should not depend solely on transient delivery.
- Idempotent intent
- Repeated input should not automatically create repeated business effects.
- Explicit external outcomes
- Success, failure, and uncertainty should be distinguishable.
- Reconciliation
- Ambiguous outcomes should be reviewed rather than blindly retried.
- Audit-oriented history
- Important changes and decisions should be traceable.
- Recoverable workflows
- Failures should have a path toward controlled recovery.
Security across the platform
Connected by design.
Bounded by design.
Security is part of the intended relationship between communication, context, service records, and external actions. Each connection should have an understood scope.
Limit the reach of each integration
Least privilege, explicit integration boundaries, and controlled credentials should define what each connection can access and do.
Keep access and environments deliberate
Identity and authorization should be considered alongside environment separation and the requirements of the connected systems.
Keep decisions open to review
Human review, deliberate handling of uncertain outcomes, and traceability should support controlled action across the workflow.
Solution areas
A shared model for different operating environments.
These potential uses connect the platform direction to the work organizations need to coordinate. They describe intended fit, not existing implementations.
Contact centers
Connector with downstream service or operational workflows: carry interaction context toward responsible follow-through.
Enterprise workflows
Connector orchestration with review, approval, and connected actions: coordinate work across operational systems.
Government & public sector
Structured workflows, control, and traceability: a product direction for environments with deliberate review and accountability requirements.
Platform adoption
Different starting points. A connected direction.
Organizations may eventually use OREA around an existing service platform, with OREA-native service management, or across operational systems. These models describe product direction and are not statements of production readiness.
Model A
OREA Connector + existing ITSM
Existing ITSM remains authoritative. Connector provides the intended integration and orchestration path around the system of record.
Model B
OREA Connector + OREA ITSM
An integrated OREA service-management environment, with Connector coordinating connected work and ITSM providing the native service destination.
Model C
OREA Connector + operational systems
Cross-system orchestration without requiring ITSM for every workflow, connecting operational activity through context and controlled actions.
Application architecture direction
Separate surfaces. A coherent product model.
The public website, future authenticated application, documentation, and API have distinct roles in the conceptual architecture.
- Public website
orea.systems
Product direction, architecture, and public information.
- Future authenticated application
app.orea.systems
Potential workspaces:
- Connector
- ITSM
- Administration
- Integrations
- Security / settings
- Documentation
docs.orea.systems
A dedicated destination for product and integration guidance.
- API direction
api.orea.systems
A distinct surface for intended programmatic access.
These destinations describe architecture direction and do not establish that each service is currently deployed. Domain names are shown as conceptual references, not links to available services.
Choice of adoption
A platform direction without forced replacement.
OREA Connector is being designed so adopting integration and orchestration does not necessarily mean replacing an existing ITSM platform.
Organizations can retain an existing service system as the authoritative record while exploring Connector for communication, context, and coordinated work.
OREA ITSM is a native service-management option within the broader platform direction. It is not required for every Connector deployment or every operational workflow.
The intended model allows organizations to adopt different parts according to their needs, systems, and operating requirements.
Development status
Built in stages.
Status made visible.
OREA Systems is under active development. Product direction, development integrations, and planned capabilities are identified so the intended model can be understood in context.
- Active development
OREA Platform
The architecture, relationships, and conceptual workflows on this page describe the platform being developed.
- In development
OREA Connector
Current development integration work and planned connectors form part of the ongoing integration and orchestration direction.
- In development
OREA ITSM
The OREA-native service-management layer is being developed within the broader platform model.
Security and deployment requirements will evolve with actual environments. This page describes development direction rather than general commercial availability.
The OREA Platform
Connect the systems.
Keep the context.
Control the workflow.
Explore how OREA Systems is being designed as a connected operating layer for service and operational work.