Bind actions to the selected tenant

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

One account connects A and subsidiary B, while the user requests B’s invoices. Teaching IDs are TA/TB; list order is not identity and successful authentication can still address the wrong tenant.

Mechanism

Inspect current authorized connections for stable organization IDs. Match B uniquely, carry TB explicitly through pages/details and check response ownership. Ambiguous/missing connections require identity clarification, not scope expansion. Record tenant/query scope without credentials and refresh bindings after switches.

Bad example

Omit tenant_id and assume first is B, delivering A invoices as B.

Good example

Match subsidiary B to TB using current connections and explicitly use tenant_id=TB for permitted pages/details. Verify response/labels; if unresolved, report the gap and request identity instead of trying other tenants.

Why the change matters

Authentication concerns access identity, not the organization intended now. Explicit IDs across calls/results prevent ordering changes from redirecting the task.

Observable expectation

Teaching reordered connections still select TB; TA responses cannot become B results. Pagination/details retain TB and gaps remain visible. Same-name organizations cannot default to first.

Limits

Frozen default behavior is dated and actual SDK contracts need checking. Tenant fields neither authorize access nor prove service isolation. This article connects to no invoice service.