Model Group Membership

Last updated: September 22, 2026Applies to current supported NIM releases

Data model · Group membership

Connect separate member and group tables through a membership table so NIM role models can manage access safely.

The three-table pattern

Group membership is an advanced, optional data model. It requires three crud_objects entries:

Table	Contains	Needs a key?
Member table	Users, employees, or other assignable identities	Yes
Group table	Groups, roles, or access containers	Yes
Membership table	The relationship between one member and one group	No

The membership table declares groupmembership and references the other two tables. Its operations must include the calls that add and remove a member.

Example structure

"memberships": {
  "resources": {
    "member_id": "string*",
    "group_id": "string*"
  },
  "operations": {
    "add_member": { "method": "post", "call": { "mode": "normal", "path": "/groups/{group_id}/members" } },
    "remove_member": { "method": "delete", "call": { "mode": "normal", "path": "/groups/{group_id}/members/{member_id}" } }
  },
  "groupmembership": {
    "add_operation": "add_member",
    "remove_operation": "remove_member",
    "member_table": "users",
    "group_table": "groups",
    "member_attributes": { "id": "member_id" },
    "group_attributes": { "id": "group_id" }
  }
}

Map the relationship deliberately

member_attributes maps an identifier from the member table to a resource on the membership table. group_attributes does the same for the group table. The usual mapping is each source table's stable key, but an API can require a different field.

Property	Must reference
add_operation	An operation on this membership table that creates membership
remove_operation	An operation on this membership table that removes membership
member_table	A crud_objects member table with a stable key
group_table	A crud_objects group table with a stable key
member_attributes / group_attributes	Resources that carry the API identifiers used by the add/remove paths or bodies

Test in the safe order

1. Collect users and groups; verify each table's key.
2. Collect memberships and confirm every membership maps to one known user and group.
3. Test one add operation with a disposable group.
4. Test the matching remove operation and verify the API and NIM results.
5. Only then use the table in a role model.

Do not use a membership table as a normal keyed entity

Memberships are relationships, not standalone identities. Do not assign a normal table key unless the API genuinely provides a stable, useful membership identifier and your model needs it.

Next: configure the operations that collect and manage each table.