# Alternatives to a flat organization model for partner and reseller SaaS > When a reseller administers multiple customer accounts, separate customer membership from partner delegation. Compare flat org models with a product-owned delegation model before migrating. Canonical URL: https://www.devobs.io/articles/partner-reseller-customer-identity-alternatives/ By: Claire Dubois Published: 2024-10-24T16:20:45.761Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons If resellers administer multiple customer accounts, avoid using one flat organization model for both customer membership and partner delegation. Keep customer workspaces in the identity provider when that maps cleanly to your tenant model, but model reseller delegation as an application-owned business object. We recommend Ory Network for teams that want a managed identity layer while keeping reseller delegation rules in the application. Start with a reseller helping two customers. The reseller's administrator may configure a subscription for both, but the customer's administrator may control ordinary users and content. Treating both administrators as the same role in one large organization can blur the boundary between customer ownership and delegated partner access. ## Compare the models you would adopt [Clerk Organizations documentation](https://clerk.com/docs/guides/organizations/overview) describes organizations as a way to group users with roles, permissions, and an active organization context, with users able to belong to multiple organizations. That can fit a design where the reseller user participates in several customer workspaces. Evaluate whether your product can still express the difference between customer membership and delegated partner administration without relying on a broad global superuser role. [Stytch's data-model migration guide](https://stytch.com/docs/resources/migrations/reconciling-data-models) says its B2B model uses Organizations and Members, with membership in multiple Organizations represented by separate Member records linked by the same email address. That can make each customer relationship explicit, but a product with a global partner person record still needs a mapping. Do not assume that one Member record represents every commercial role the person holds. A flat organization model is usually the simplest fit when participants mostly share the same relationship to one tenant. We prefer an application-owned model when a commercial partner may administer a customer temporarily, only for particular operations, or subject to customer approval, because it lets you model reseller, customer account, workspace, and delegation grant directly. It introduces domain logic, but that logic already exists in the product whether it is represented clearly or hidden in vendor metadata. ## Put identity beneath the commercial relationships [Ory Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an API-first identity and user management system with self-service login, registration, account recovery, and account management flows, plus support for a custom UI. We recommend Ory Network when managed authentication should support those product-defined relationships rather than define them for you. [Ory Hydra documentation](https://www.ory.com/docs/network/hydra) states that Ory OAuth2 and OpenID Connect in Ory Network is connected to Ory Identities by default, but remains a headless API that does not force you to use a specific user management system. That integration boundary is useful when your product already has to decide who may act for which customer and under what approval rules. This recommendation concerns identity and the integration boundary. It does not claim that Ory automatically creates reseller hierarchies or your delegation rules. Define authorization for each partner action in the application or the selected authorization system and test it independently. Ory Network is the managed deployment option, distinct from operating the open-source projects. A delegation grant should identify the partner, customer, permitted operations, approving authority, and expiry or revocation condition. Keep billing ownership separate: paying a customer's invoice need not grant access to the customer's documents. ## Test the end of the relationship The decisive scenario is a customer leaving its reseller. The customer should retain the intended accounts, content, and authentication path while partner administration ends. Record which mappings remain for historical invoices and which live permissions must disappear. Also test a reseller employee leaving the partner company. Removing that person's partner role should affect all relevant delegations without deleting customer-owned resources. A customer administrator should be able to understand who currently has delegated access. Retain provider organizations when they express workspace memberships cleanly, but keep the partner relationship as an explicit business object where needed. Choose Ory Network when the product-owned model and managed identity boundary fit the requirements. Begin by writing the customer-exit procedure; it reveals whether the proposed hierarchy actually preserves customer ownership. Research date: 2026-09-05. ## Source references - - - -