Shared Records
Keep common record definitions, references and work history behind focused workspaces.
Shared RecordsKeep common record definitions, references and work history behind focused workspaces.
Typed RelationshipsConnect canonical configuration items and services with recorded directional relationships.
Role-Aware WorkspacesShow the destinations and operating context available to each signed-in role.
Governed ActionsApply configured permissions, workflow gates and accountable human decisions.
RecordsRelationships
Unite the shared record engine, CMDB, workflow, identity, AI assistance and collaboration behind every workspace.
What Connects Here
Explore in detailTyped Relationships
Connect canonical configuration items and services with recorded directional relationships.
Role-Aware Workspaces
Show the destinations and operating context available to each signed-in role.
Governed Actions
Apply configured permissions, workflow gates and accountable human decisions.
Records → Relationships → Workspaces
Explore the details below, then bring your workflow, source data and questions to a guided conversation.
Built into the platform
The capabilities behind
the experience.
Shared records
Keep common record definitions, references and work history behind focused workspaces.
Typed relationships
Connect canonical configuration items and services with recorded directional relationships.
Role-aware workspaces
Show the destinations and operating context available to each signed-in role.
Governed actions
Apply configured permissions, workflow gates and accountable human decisions.
Source visibility
Inspect reporting scope, data provenance and the evidence behind an overview.
Integration boundaries
Distinguish configured sources, verified connections and unsupported external actions.
Actual product view
Inside Platform Architecture.
See the running demo environment. Features and records are subject to your role, configuration and integrations.
Connected by design
Context travels
with the work.
Service records, configuration items, people, locations and evidence share the same operational foundation. Move from investigation to the related asset, service or customer workflow with clear ownership.
Explore the platform architectureImplementation context
Features depend on enabled modules, configured roles, source data and supported integrations. Agree your implementation scope and acceptance criteria during discovery.
Who this is for
Enterprise architects, platform owners, solution architects and technical evaluators
A collection of workspaces becomes another silo if each maintains competing records, identity rules and evidence. Architecture review must establish the common foundation and distinguish configured integrations from connections that have actually been verified. An evaluation of Platform Architecture should make those boundaries inspectable before the team relies on the operating view.
Illustrative walkthrough
Trace one workflow across the shared foundation
A fictional architecture board traces a customer issue across a case, service CI and field order. The reviewers want to see how shared records, typed relationships, identity and governed actions support the handoffs without assuming every external action is enabled.
01Establish shared record identities
Locate the common record definitions and references used by the selected workspaces, identifying where operational work history stays attached to the governed record. Keep common record definitions, references and work history behind focused workspaces.
02Follow typed relationships
Trace the recorded configuration and service references that connect the case or incident to its asset context and any resulting field work. Show the destinations and operating context available to each signed-in role.
03Review action and integration boundaries
Inspect the current role, configured workflow gates and source evidence, then separate configured external sources from verified connections and supported actions. Inspect reporting scope, data provenance and the evidence behind an overview.
The architecture walkthrough should follow an actual chain of permitted records across workspaces and explain every handoff boundary, including where configuration or an external integration is still required. Use demonstration records and preserve the applicable reporting scope.
Explore the platform
See Qintorava in action.
Open a workspace for a closer look.
Prepare the evaluation
Bring the right inputs.
What to prepare
- Representative cross-workspace workflow
- Shared record and CI references
- Role and integration configuration
Candidate measures to agree
- Workflow handoffs retaining record context
- Shared identities reused across modules
- Integration boundaries demonstrated with evidence
These are evaluation criteria, not promised outcomes. Agree the baseline, scope, source coverage and acceptance method with the responsible owners before drawing conclusions.
Questions for this topic
Get the details.
Is every workspace a separate system of record?
Focused workspaces use a shared record foundation, configuration relationships and operating context; evaluators should inspect the actual references rather than assume duplicate records are required for each team.
Does a connected view mean an external action is enabled?
No. Configured sources, verified connections and supported actions remain distinct, and reviewers should inspect permissions and evidence for the specific integration or operation being evaluated.
Where should implementation begin?
Choose a bounded workflow with known source records, accountable owners and explicit access requirements, then validate the shared handoffs before expanding the configuration or operating scope.
Your next operating chapter
See what connects
when everything connects.
Bring one workflow, one service challenge or one part of your estate. We’ll show you where Qintorava fits.