From workflow model to trusted transaction

Operon.Cloud turns events already produced by an operation into trusted evidence. It does not replace the systems where work happens. It gives teams a consistent way to see where work is, how it moves, who participated, and what changed.

Workspace

The top-level operational boundary for related Workstreams.

Workstream

One bounded business process. Model a coherent workflow, not an entire enterprise.

Case

A correlated sequence of transactions representing one unit of work, such as a claim, request, or order.

State or queue

Where a Case currently waits or receives work.

Each observed event becomes a signed Transaction. Transactions with the same correlation ID form a Case, and their Interactions explain both the work performed and the path taken.

1. Open Workspaces. Select an existing Workspace or create one for the operational boundary you want to measure.
2. Choose Internal or Production deliberately. The Workspace type is permanent after creation.
3. Open DIDs and create the Organization, System, API Client, or Person identities needed by the first workflow.
4. Create one Workstream with a clear name, outcome, and boundary. Avoid combining unrelated workflows simply because they share a department or application.

The catalog is the shared contract between the operational design and every connected application. Configure it before issuing credentials.

State and Interaction Source Codes are customer-controlled catalog values that let external code find the current Operon object without storing its generated platform ID.

• State Source Codes are case-insensitively unique among states in one Workstream. Interaction Source Codes follow the same rule among interactions. A code may be reused in another Workstream.
• SDK lookup trims whitespace and matches case-insensitively.
• Lookup searches the fetched catalog and does not determine whether an inactive or archived Interaction is eligible for submission.
• Client API remains authoritative for Workstream membership, ownership, and submission eligibility.
• Direct platform ID integrations remain supported when the calling application intentionally owns that ID lifecycle.

1. Review Draft, Active, Inactive, and Archived statuses. Activate only the states, Participants, Interactions, and Workstream intended for the integration.
2. Open M2M Clients and create a Workstream client. Select the active Workspace, Workstream, and Participant that define its operating scope.
3. Save the client ID and client secret securely. The secret is shown only once. Regenerating it invalidates the previous secret.
4. Give the developer the Source Codes, expected Case correlation strategy, environment, and a safe way to receive credentials.

After the first event is submitted, find it in Transactions Explorer and confirm its Case path in Loop Atlas before expanding the configuration.

Before writing code, agree on the operational contract. This prevents a technically successful integration from producing an incorrect Case path.

Create one client per Operon credential configuration and reuse it for the application lifetime. Do not create or initialize a client for every request or transaction. When you use Source Codes, the reusable operation fetches current configuration, resolves the codes, and submits with the resulting platform IDs.

1. Create onceBuild one client for each credential set.
2. Init onceAuthenticate at startup and surface errors early.
3. ReusePass the existing client into transaction operations.
4. Close onceDispose the client during application shutdown.

client, err := operon.NewClient(operon.Config{
    ClientID: os.Getenv("OPERON_CLIENT_ID"),
    ClientSecret: os.Getenv("OPERON_CLIENT_SECRET"),
})
if err != nil { return err }
if err := client.Init(ctx); err != nil { return err }

func submitClaimReview(ctx context.Context, client *operon.Client) error {
    workstream, err := client.GetWorkstream(ctx)
    if err != nil { return err }
    state := workstream.FindStateBySourceCode("READY_FOR_REVIEW")
    if state == nil { return errors.New("state mapping not configured") }

    catalog, err := client.GetWorkstreamInteractions(ctx)
    if err != nil { return err }
    interaction := catalog.FindInteractionBySourceCode("CLAIM_REVIEWED")
    if interaction == nil { return errors.New("interaction mapping not configured") }

    activeSeconds := 37
    _, err = client.SubmitTransaction(ctx, operon.TransactionRequest{
        CorrelationID: "case-123", InteractionID: interaction.ID,
        StateID: state.ID, StateLabel: state.Name,
        ActiveTimeSeconds: &activeSeconds,
        Payload: []byte("{\"caseId\":\"case-123\"}"),
    })
    return err
}

client.Close()

Client credentials are the primary server-to-server path. Injected token providers and caller-owned PATs are advanced alternatives when the application already owns a scoped token lifecycle.

Common integration failures

Source Code not found

Confirm the code and Workstream, refresh the catalog, and verify that an administrator has not changed or cleared the mapping.

Interaction resolves but submission is rejected

Check Workstream membership, status, Participant ownership, and submission eligibility. Lookup itself does not filter by status.

Case appears as separate paths

Check that every event for the business Case uses exactly the same correlation ID and that a new ID is used for each new Case.

Authentication fails after rotation

Confirm that the application received the newly generated secret and that the M2M client, Workstream, and Participant are active.