OREA ITSM
In developmentOREA ITSM is being developed to keep requests, communication, approvals, workflow context, ownership, and service history connected around the work being performed.
When service context separates
In fragmented service operations, the record can tell only part of the story. The rest lives in inboxes, conversations, and separate decision chains.
OREA ITSM is being designed around a simple principle: important service context should stay associated with the work.
An email starts the work. A technician creates or updates a ticket.
The requester replies by email; a technician discussion continues outside the record.
Approval is requested in a separate email, while concurrence is provided somewhere else.
Another technician has the ticket, but may not have the complete history.
The service record
OREA ITSM is being designed so important service context can remain associated with the service record, instead of being fragmented across unrelated tools.
Request / incident
The connected center
The work and its related context
A request or incident anchors the record. Communication, decisions, responsibility, and history are intended to remain connected to it as the work evolves.
Incident management
OREA ITSM is being developed to give incidents a clear path from the first report to resolution, with the people, activity, and service context kept together.
A status tells you where an incident stands. The record should also explain what happened, who is responsible, and what comes next.
Bring the reported issue, requester context, and relevant service information into a record the team can work from.
Keep ownership, assignment, priority, and status alongside the activity history so the next action has a clear starting point.
Connect investigation, escalation, and requester communication to the resolution, preserving the context behind the outcome.
Service requests
The planned request workflow brings structure to everyday service needs, connecting the initial request to assignment, approvals, fulfillment, and completion.
Structured intake, request categories, and requester context establish what is needed and the information required to begin.
Route the request to an owner and include an approval step where the service workflow calls for one.
Give the responsible team defined fulfillment steps, visible progress, and a place to keep requester communication connected to the work.
Record completion and the result of the request so the requester and the service team share the same context.
Communication that stays with the work
The intended experience connects a requester's email response to the underlying service record, so a technician can follow the conversation alongside the work.
The work provides the context for the conversation.
An email is associated with that service record.
The requester responds to the linked conversation.
The response is intended to retain its relationship to the work.
The reply becomes part of the service history.
The conversation is available where the work continues.
This communication continuity is in development. OREA Connector may provide communication and integration pathways for external channels.
Approval · Concurrence · Review
Many enterprise and public-sector workflows rely on approval or concurrence. OREA ITSM is intended to give those decisions a structured relationship to the service record, even when a conversation begins elsewhere.
Planned decision workflows connect the request for review with its outcome. The service record is intended to retain:
Review requirements are intended to be configurable. Work that does not need approval or concurrence can continue on its own path.
Request
Review required?
Continue work
No approval or concurrence is needed for this path.
Request the configured review.
Alternative outcomes
The outcome and resulting action remain associated with the service record.
Ownership and handoffs
Service work often moves between people. OREA ITSM is being designed to keep responsibility and context visible throughout that movement.
Visible owners, queues, and workgroups are intended to make responsibility clear as work is assigned and reprioritized.
Assignment history and handoff context are planned to preserve what has been tried, why the work is moving, and what the receiving team needs.
Triage and escalation
When the destination is unclear, the intended workflow gives the work an owned triage destination. A responsible person or workgroup can review the context and decide the next assignment.
Escalation should make the next responsibility explicit and carry the reason for the handoff with it.
Ownership is part of the workflow, including the moments that need human judgment.
Knowledge
OREA ITSM is being developed to connect service knowledge with the people and records that need it, from technician guidance to information for requesters.
Knowledge articles are planned to hold service information and repeatable guidance that teams can maintain and reference.
Relevant knowledge should be available alongside the service record, helping technicians use established procedures during investigation and fulfillment.
Requester-facing information is intended to explain common service needs and next steps in clear, useful language.
Linked records and resolution context are planned to keep an article connected to the work it informs and the experience that can improve it.
Workflow automation
Planned workflow automation uses defined rules to coordinate repeatable service work, with approvals and human review where the process calls for them.
OREA Connector may support connected actions across systems as this workflow direction develops.
Explore OREA ConnectorPlanned rule and review flow
Set the conditions, responsible owner, and permitted next step for a repeatable service workflow.
Include human review when an approval is required or the work needs a decision before it proceeds.
Carry the workflow into an update, notification, or connected action, with its outcome available for follow-up.
OREA ITSM + OREA Connector
OREA ITSM is in development as a native service management destination within a wider, vendor-neutral integration model.
Where work begins
Requests, conversations, and operational events provide the starting context.
Integration & orchestration
A planned layer for connecting sources, coordinating workflows, and passing context.
In developmentService management
A planned native destination for the service record and the work around it.
In developmentConnector is being designed to serve external ITSM and workflow platforms as well as OREA ITSM. OREA ITSM is not required for every Connector deployment.
The products have distinct responsibilities: Connector focuses on integration and orchestration; ITSM focuses on service management. The relationship shown here is conceptual and may evolve during development.
Explore OREA ConnectorConceptual workspace structure
This proposed structure describes how the in-development product could organize service work. It is a planning model; the workspace design may evolve.
Operational visibility
Planned visibility is intended to help teams understand where work stands, who owns it, and what needs attention across a service process.
Planned visibility areas
These labels describe product direction. Reporting views and their implementation remain in development.
Traceable service history
The intended audit history brings actions, decisions, and communication into the context of a record so teams can understand its path through the service process.
When a record began, how it entered the service process, and how ownership was assigned or transferred.
Changes in status, workflow steps, and the handoffs that moved the work forward.
The decisions requested, the people involved, and the approval or concurrence recorded.
External integration activity, requester communication, and internal updates associated with the service record.
Audit history is a planned capability of OREA ITSM.
Experience principles
These principles guide the in-development experience, from the individual record to the wider service process.
Organizational fit
OREA ITSM is being designed with enterprise and public-sector organizations, IT service desks, and managed service environments in mind.
Clear responsibilities, team queues, and deliberate handoffs across a service process.
Approvals, concurrence, and traceability for work that needs a recorded decision.
Workflow flexibility shaped around organizational needs, with security and control as design priorities.
These are intended use contexts and design priorities for a product in development.
Security & boundaries
Security priorities are part of the product design. Requirements and implementation will evolve as OREA ITSM develops.
Role-based access and least-privilege permissions are intended to define who can see records and take action.
Protected credentials and controlled integration paths are design priorities for how external systems may participate.
Recorded actions and configurable approval requirements are planned to make service decisions traceable.
Environment boundaries are a design priority. The public website is separate from the planned operational application.
Capability direction
OREA ITSM is in development. These planned capabilities describe the intended scope; the product model and implementation may evolve.
A broader direction for connected capabilities.
Integration & orchestration
In developmentService management
In developmentThis conceptual model may evolve as the products develop.
Connected service operations
Learn how OREA Systems is being designed for connected service operations.
