How apps work together

Shared context, explicit connections#

Opser brings apps into one workspace with a shared identity and permission system. Each app still owns its records and behavior. Apps work together by exposing capabilities and declaring the ones they use.

That distinction matters when you ask an agent to connect workflows. Name the source, the trigger or request, the destination, and the result. The agent can inspect the available interfaces and identify anything that needs to be built.

Contracts request an operation#

A contract is a named operation one app offers to another. A provider might offer “get equipment availability.” A requesting app declares that it consumes that operation, sends the required inputs, and gets a result.

The platform checks the declared provider and consumer relationship. Resource rules and the authority under which the request runs also apply. An app cannot simply call an arbitrary operation in another app because both are installed.

Use a contract when a workflow needs an answer or action now. If the provider is missing, unavailable, or denies access, the requesting workflow needs to handle that outcome. A useful custom app explains the problem instead of presenting an empty result as success.

Events announce a change#

An event describes something that happened, such as an equipment return being recorded. The emitting app declares the event, and a receiving app declares its subscription and implements the response.

Events let workflows react without making the original app perform every downstream step. A request system could react to a return by checking a waiting list. That connection must be implemented; an event name alone does not create the behavior.

Delivery can be retried, so a receiving workflow must handle the same event more than once without duplicating its work. Events are delivered to the subscriptions active when they are emitted. A new subscription does not automatically replay the past, and a failed delivery is not a guarantee of eventual completion. Check the resulting records when a downstream action is missing.

Notifications inform people#

A notification is a message for a person. An event is a signal for a workflow. The same business change may produce both, but they are not interchangeable.

Apps can declare notification types that appear in Settings → Notifications, with bell and email preferences where supported. Turning off an email notification does not disable the underlying business event or automation. Read Inbox & notifications for delivery preferences.

Live views reuse read operations#

An app can explicitly expose a read operation for a dashboard or other composed view. Its input and output describe the data the view can use, and it keeps the app's own logic, so the view keeps working when the app changes its tables.

The agent prefers such an operation when one exists. Without one, a dashboard can still read the tables of the apps you can open, read-only, the same way the agent's data tool does; it never shows an app you cannot open. See Dashboards & live views.

External connections are a separate boundary#

Agent connections authorize an agent to use an external service. An app may instead declare its own integration for incoming or outgoing data, with separate setup and access requirements. Neither connection grants general access to every workspace record.

For a connected workflow, verify the account, the allowed operations, who initiates the work, and where the result is stored. Read Connect your tools for agent connections.

Brief the agent with an end-to-end example#

When equipment is returned, check the waiting requests, identify the next eligible person, and notify the coordinator. Do not approve the next checkout automatically. Show me how a repeated event and a missing destination app are handled.

Review the normal path, an unavailable dependency, denied access, and a repeated event. The connection is complete when the downstream behavior works with the intended permissions, not just when the original action succeeds.