# What practices have folks used for logically grouping federated entities

**URL:** <https://community.apollographql.com/t/what-practices-have-folks-used-for-logically-grouping-federated-entities/9151>\
**Category:** API Design, Strategy & Governance\
**Created:** [June 6, 2025, 2:48pm UTC](https://community.apollographql.com/t/what-practices-have-folks-used-for-logically-grouping-federated-entities/9151 "2025-06-06T14:48:54Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mike-OLaughlen\_spglo](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/mike-olaughlen_spglo/32/6014_2.png) [@Mike-OLaughlen\_spglo](https://community.apollographql.com/u/Mike-OLaughlen_spglo)\
**Post date:** [June 6, 2025, 2:48pm UTC](https://community.apollographql.com/t/what-practices-have-folks-used-for-logically-grouping-federated-entities/9151/1 "2025-06-06T14:48:54Z")

</div>

My team at S&P Global is reviewing ways that we can logically group companies based on a number of criteria.

Our supergraph defines a company as a federated entity (e.g. Instn) and the team is looking to provide a common capability in the institution subgraph to define sectors of companies based on such things as headquarters (geography), industry, and other aspects.

One idea is to define a federated InstnSector entity that would allow other subgraphs to operate against a collection (e.g. [Instn!]!) but how that would work may lead to defining the set of Instn identifiers via encoded string (base64 encoding of json / csv) which seems less than ideal from a design perspective.

Another idea is to avoid defining the InstnSector as a GQL entity and have the subgraphs directly pull from the owning insitution subgraph via an GQL intraservice call (e.g. client-\>router-\>subgraph-\>router-\>institution) which is less than idea from the context of observability and cost analysis at the router level.

How have others here tackled this kind of use case in the past?