A map of things and their relationships
A workplace operations graph is a way to represent operational things and the relationships between them. Think of a map rather than a spreadsheet: a person belongs to a team, holds an identity, uses a device and receives access to an application. Each connection adds meaning that an isolated record cannot provide.
In graph terminology, the things are nodes and the connections are edges. You do not need that terminology to use the idea. The practical question is whether you can follow a relationship to answer a real operational question, understand where the information came from and recognise when the connection still needs checking.
People, teams, identities and devices
A person and an identity are not the same thing. One person may have several accounts, while a shared or service identity may not belong to an individual employee. Team membership adds organisational context, but it does not by itself prove that someone should have a particular permission.
Devices introduce further relationships: assigned user, custodian, owner and managing system can all differ. A shared meeting-room device should not be forced into a single-employee model. Useful connections describe their meaning clearly and, where relevant, their effective dates. This allows a team to distinguish a current assignment from a historical one and a reported association from an approved responsibility.
Applications, licences, subscriptions and business systems
An application is a service or tool people use. A licence represents an entitlement under particular terms. A subscription represents a commercial arrangement that may cover many licences, applications or billing periods. Connecting these concepts helps explain why an account, an assigned seat and a payable invoice are not interchangeable units.
Business systems provide different parts of this picture. An identity service may report account access, an application portal may report licence assignment, and procurement or finance may hold the contract and invoice. The relationship between them should state what is actually known. Access through an identity provider does not establish actual application usage, and an invoice does not identify every user who benefits from a service.
Operational records, security events and evidence
Operational records include requests, approvals, assignments and workflow outcomes. Linking them to the affected person, device or application helps explain not only the current state but also the decisions behind it. A security event can add context about a relevant identity or endpoint without automatically proving a breach or a policy failure.
Evidence and compliance records connect observations to review questions and control responsibilities. A policy document expresses an expectation; an approval records a decision; a verified result supports a claim about an outcome. These are different kinds of information. Append-only audit and signed evidence export mechanisms can support traceability, but not all records are immutable, and integrity controls are neither certification nor legal guarantees. Human review remains necessary.
A fictional example: following a licence decision
Imagine a fictional review of a design application used by Lina. An imported HR record places Lina in Marketing. A manually maintained procurement record names the subscription owner. A matching email address suggests a connection between Lina and an application account, but that link remains inferred until checked against a reliable identifier or confirmed source.
After verification, the reviewer can follow Lina to the account, assigned licence and relevant subscription. Actual usage is still unknown if no suitable usage information is available. A team move therefore prompts a review rather than automatic access removal. Relationships make the question easier to investigate; they do not supply missing facts. This example illustrates the concept and does not describe measured customer outcomes.
Evaluate the graph by the questions it can support
Lojycal uses connected operational context across its workplace operations platform. The graph concept explains that approach; it is not a promise that every relationship is automatically discovered, supported or current. Confirm available sources and relationships for your plan and workspace, including provider permissions, mappings and credentials. Access to operational information and actions remains subject to organisation membership and roles.
Explore /operational-graph and use /contact to discuss a representative scenario. Evaluate whether the view helps a colleague make a defensible decision, including when it correctly leaves a question unanswered.
- Choose a question requiring several relationships, such as who owns a subscription used by a departing employee.
- Check the meaning, source and freshness of each link, including shared-account and reassignment exceptions.
- Require imported, manual, inferred, verified and unknown information to be distinguishable during review.
- Test how incorrect links are resolved and how approved action outcomes are checked against source systems.