Managing Model Aggregate Access by Representative

What this is

In Orion Connect, access to a model aggregate is controlled through two mechanisms:

1. Ownership — a representative linked directly to the model aggregate who can both use and edit it.
2. Entity access list — a set of representatives who can use (but not edit) the model aggregate, governed by the include flag.

Your integration may need to manage one or both of these depending on whether the representative needs read-only access or full edit rights.

Who this guide is for

Technical partners or internal teams integrating with the Orion Connect Web API.

What you need

• Your Orion Connect API base URL.
• A valid Orion Connect token for a user who is allowed to edit model aggregates.
• Requests are typically sent as application/json.

---

Key concepts

Owner vs access

A representative can interact with a model aggregate in two ways:

If your integration needs a representative to edit a model aggregate, that representative must be set as the owner. Adding them to the entities list alone is not sufficient for edit rights.

The include flag (allowlist vs denylist)

The include field on the model aggregate controls how the entities list is interpreted:

include value	Behavior	OC UI label
false (0)	Allowlist — only representatives in the entities list get access	“Exclude All But”
true (1)	Denylist — all representatives except those in the entities list get access	“Include All But”

The default value for include on newly created model aggregates is controlled by the Default_ModelAgg_Include database entity option in each tenant.

entityEnum for representative access

For representative access on model aggregates, entityEnum should be 4 (Representative).

This value is defined in the system-wide Entity enum and is what all existing code paths (UI, stored procedures, access queries) expect for representative entity rows.

Internal support note

If an internal Orion team needs to confirm the full set of enum mappings.

---

Read the current model aggregate first

Before making changes, load the model aggregate so you can see the current state.

Request

Method	GET
Path	/v1/Trading/ModelAggs/{modelAggId}

Example

GET /v1/Trading/ModelAggs/9876

Key fields in the response

Why this matters

Updates to entities should be treated as a full desired state. Merge your changes with the existing list and send the complete set you want to keep. If you omit an existing entity, that entity may lose access.

---

Update the model aggregate

Request

Method	PUT
Path	/v1/Trading/ModelAggs/{modelAggId}

Setting representative access (entities list)

Each entry in the entities array needs:

• entityId — the representative’s ID
• entityEnum — 4 (Representative)

Setting the owner

To make a representative the owner of the model aggregate (allowing them to edit it), set these fields on the model aggregate itself:

• entityId — the representative’s ID
• entityEnum — 4 (Representative)

Example payload

{ "id": 9876, "entityId": 789, "entityEnum": 4, "include": false, "entities": [ { "entityId": 123, "entityEnum": 4 }, { "entityId": 456, "entityEnum": 4 } ] }

In this example:

• Rep 789 is the owner and can edit the model aggregate.
• include is false, so the entities list is an allowlist.
• Reps 123 and 456 have access (can use the model aggregate, but cannot edit it).
• Rep 789 (the owner) also has access implicitly through ownership.

Important

This example shows the permission-related portion of the payload only. Your environment may require additional fields on update, so the safest pattern is to:

1. GET the current model aggregate
2. Preserve required fields from that response
3. Update the entities list, include, entityId, and/or entityEnum as needed
4. PUT the complete payload back

---

Check edit rights before updating

Request

Method	GET
Path	/v1/Trading/ModelAggs/{modelAggId}/CanMaintain

Example

GET /v1/Trading/ModelAggs/9876/CanMaintain

Returns owned and canMaintain flags. Use this to confirm the current user can edit the aggregate before attempting an update.

---

Permission requirements

There are two common reasons an update may fail even when the aggregate can be read:

1. The signed-in user may not be the owner of the model aggregate. Only the owner (or an admin/advisor-level user) can edit it.
2. The signed-in user may not have Model Aggregates permission at edit level.

If the update fails with 403 Forbidden, confirm both ownership and the user’s permissions.

---

Eclipse vs Orion Connect

System	What you are editing	Typical API pattern
Eclipse	teams on a model	teamIds on PUT /v1/modeling/models/{id}
Orion Connect	entities on a model aggregate	entities on PUT /v1/Trading/ModelAggs/{id}

These solve a similar business problem, but they are managed through different objects and endpoints.

---

Checklist for integrators

• Use a user account that is permitted to edit model aggregate permissions.
• GET the model aggregate and review the current entities, include, entityId, and entityEnum.
• Build the final list of entities to keep, add, or remove.
• Use entityEnum: 4 for representative access.
• Set the include flag to control allowlist (false) vs denylist (true) behavior.
• If a representative needs to edit the model aggregate, set them as the owner via entityId and entityEnum on the model aggregate itself.
• PUT the updated aggregate using the full payload required by your environment.