Skip to content
Albumi Docs

Organizations

An Organization in Albumi is a node in the company’s internal structure — a department, a division, a region, a team. Every landscape entity belongs to exactly one Organization, and that classification is what drives portfolio views: “all Applications owned by Finance”, “all Integrations run by the Platform team”, “every IT Component that sits under EMEA”.

Organization is about whose part of the business an entity lives in. It is not about who is allowed to edit that entity. Those are two different questions and Albumi answers them with two different mechanisms — mixing them up is the single most common modeling mistake on this entity, and the rest of this page exists mostly to prevent it.

What an Organization is

Section titled “What an Organization is”

An Organization represents a standing unit of the business. It has a name, an optional description, a type (Company, Legal Entity, Division, Region, Department, Team, Unit), and a position in the organizational tree.

Examples of good Organizations:

  • Finance — a department that owns financial systems.
  • EMEA — a region that runs its own localized applications.
  • Platform Engineering — a team that owns shared IT Components.
  • Acme UK Ltd — a legal entity inside a group.

Non-examples:

  • Mary Chen — a person. A single user’s accountability for an entity is captured separately as the entity’s owner, not as an Organization.
  • “CRM Replacement 2026” — a temporary change effort. That is an Initiative.
  • “Approvers” — a role or group. Permissions and roles are workspace-level settings, not Organizations.
  • “North America customers” — a customer segment. Albumi models the internal structure of your company, not market segments.

If the thing you are modeling will still exist next year under the same name, with the same remit, and you would put it on an org chart — it is an Organization. If it is a person, a project, a permission bundle, or a market slice — it is not.

The hierarchy

Section titled “The hierarchy”

Organizations form a tree. Every workspace starts with one root Organization created automatically when the workspace is provisioned. Every other Organization has exactly one parent.

A typical shape looks like this:

  • Acme Group (root)
    • Acme North America
      • Finance
      • Operations
      • Customer Service
    • Acme EMEA
      • Finance
      • Operations
    • Shared Services
      • Platform Engineering
      • Security

The tree is the primary navigation structure on the Organizations screen. It is also what powers roll-up questions: “show me every Application under Acme EMEA” walks the subtree from that node.

The root Organization is fixed

Section titled “The root Organization is fixed”

The workspace root Organization cannot have a parent. It is the top of the tree by definition, and any attempt to set a parent on it is rejected — including attempts made by a workspace Admin. This is a property of the data model itself, not a permission rule: there is no role or grant that can move the root under another node.

In practice this means: name the root after the top of the business you are modeling (the group, the company, the tenant) and treat it as permanent. If the business itself is acquired or restructured in a way that the root name no longer fits, rename the root — do not try to slot it under a new parent.

Every entity has an owning Organization

Section titled “Every entity has an owning Organization”

Each of the six landscape entities — Application, Integration, Data Object, Business Capability, IT Component, Initiative — carries exactly one organization link. That link is the answer to “which part of the business is this thing classified under”.

Rules:

  • Every entity has one. There is no “unassigned” state. If nothing specific applies, the entity sits under the workspace root Organization.
  • One, not many. An Application cannot span two Organizations in this field. If it genuinely serves two units, pick the one that funds it or is accountable for it; the other unit’s interest is expressed through realized capabilities or through Initiatives, not through a second Organization link.
  • The owning Organization is separate from the ownerUser. ownerUser names the single accountable person. organization names the unit of the business the entity belongs to. Both fields exist on every entity and they answer different questions — who the responsible human is, and which part of the company it sits in.

ownerUser can be left empty on an entity (for example, when ownership has not yet been assigned). The owning Organization is always set.

Organization is not a permission dimension

Section titled “Organization is not a permission dimension”

This is the most important thing to understand about this entity, and the easiest one to get wrong.

Putting an Application, Integration, or any other entity under the Finance Organization does not give anyone in Finance any access to that entity. Users do not inherit edit rights, view rights, or proposal rights through their own organizational position or through the entity’s organizational classification. Organization membership and entity access are completely independent.

Access in Albumi is decided by three things, none of which is Organization:

  • Workspace role — Admin, Contributor, or Viewer, assigned at the workspace level.
  • Direct ownership — whether the user is named as ownerUser on the entity.
  • Entity-level grants — explicit per-entity permissions attached to that one entity.

An Admin can edit everything. An owner can edit the entity they own directly. A Contributor without ownership proposes the change rather than editing directly. None of this is affected by which Organization the entity is classified under, or by which Organization the user sits in. For the full model, see Permissions & Roles.

Why this matters in practice: do not try to express “only the Finance team should be able to edit the financial applications” by moving those applications under the Finance Organization. It will not work — the classification has no effect on what anyone can do. To achieve that kind of restriction, name a Finance person as the ownerUser on each of those applications, or grant Contributor access on those specific entities to the Finance users who need it. Organization is the wrong lever.

What Organizations are used for

Section titled “What Organizations are used for”

With access control out of the picture, the purpose of Organization is clear and bounded:

  • Classification. Every landscape entity carries a single, consistent answer to “whose part of the business runs this”.
  • Filtering. Portfolio screens, entity lists, and search can filter by owning Organization. “Show all Applications under EMEA” is one click.
  • Reporting and roll-ups. Dashboards and reports aggregate along the Organization tree — health heatmaps per department, TIME distribution per division, integration counts per region.

That is the full list. Anything else Organization appears to offer — permissions, notifications routed by department, workflow assignment — is not there. Use the features built for those purposes instead.

Attributes on an Organization

Section titled “Attributes on an Organization”

An Organization is light on fields by design. It carries:

  • Name — how it is addressed in the rest of the product.
  • Description — an optional line or two explaining what the unit does. Useful when the name alone is ambiguous (“Operations” in which region?).
  • Type — one of Company, Legal Entity, Division, Region, Department, Team, Unit. The type is a label for filtering and visualization; it does not change behavior. Pick the closest match.
  • Parent — the Organization one level up in the tree, required on every Organization except the root.
  • Owner user — an optional person accountable for this organizational unit as a classification node (not the same as the owners of the entities classified under it).

Organizations are reference entities: they have a status of either Active or Archived, with no dated lifecycle. An active Organization is usable as a classification target on entities; an archived Organization is preserved for historical reference but should not be assigned to new entities. There is no plan / phase-in / phase-out timeline for Organizations the way there is for Applications — a department either exists today or it does not.

Common modeling mistakes

Section titled “Common modeling mistakes”

The first one is the expensive one. The rest are recoverable.

  • Using Organizations for access control. “If I put the finance apps under the Finance organization, only finance people can edit them.” No. Organization is classification; it grants zero access to anyone. Use workspace roles, ownerUser, and entity-level grants instead. See Permissions & Roles.
  • Over-deep hierarchies. Six levels deep — Group → Division → Sub-Division → Department → Sub-Department → Team → Squad — produces a tree no one navigates and classifications no one maintains. Three levels is usually enough to answer every portfolio question. If you find yourself adding a fifth or sixth level, ask whether the detail belongs in the entity’s description or in a tag, not in the tree.
  • Rebuilding the tree every reorg. When a department is renamed, rename the existing Organization in place — the ID is stable and everything classified under it stays classified. When a department is dissolved, archive it, create the new one, and reassign the entities that moved. Do not delete and recreate Organizations for a cosmetic change; you will lose continuity on historical reports and orphan any archived references.
  • Classifying something under “the Organization that uses it most”. The owning Organization is the unit that is accountable for the entity — pays for it, plans its lifecycle, names its owner — not the unit that happens to have the most users. Usage is a different question and is captured through realized capabilities and data operations, not through the Organization field.
  • Leaving everything under the root. Technically legal; practically the same as having no Organizations at all. If the entire landscape is classified under the root, filtering and roll-ups by Organization do nothing for you. Create the first two or three levels that match how the business is actually run, even if you never go deeper.
Section titled “Related”