Organisations, projects, and deliverables
Understand how your enterprise, organisations, workspaces, projects, and deliverables fit together.
On this page
- Enterprise tenantYour company’s administrative home.
- OrganisationA business unit and its configuration.
- WorkspaceShared apps, plan, and credits.
- ProjectOne brief and a shared outcome.
- Connected deliverablesAppsSlidesOther outputs
Your account identifies you. Your enterprise tenant provides the overall administrative boundary. Within it, organisations group business units, workspaces bring teams together, and projects connect a shared brief to the deliverables that fulfil it.
Availability: Organisation-level controls and the available deliverable types depend on your tenant's enterprise configuration. The hierarchy describes how work is organised; it is not an automatic grant of access.
Choose the right level
| Level | What it is for | What to check |
|---|---|---|
| Account | A person's sign-in and access to workspaces. | Each person uses their own account. |
| Enterprise tenant | The overall administrative home for your company. | Who governs models, sharing, cloud placement, and access. |
| Organisation | A business unit or other grouping inside the enterprise. | Which workspaces and configuration belong to that unit. |
| Workspace | A team working context with shared apps, credits, and settings. | Who collaborates and which workspace is active. |
| Project | A shared brief, ownership, and outcome that can connect several deliverables. | What success means and who is responsible. |
| Deliverable | An output of the project: an app, slides, or another enabled type. | Who can see, change, share, or release this output. |
Keep related work together when the same team should collaborate and share credits. A workspace can also stand on its own without an organisation grouping; not every team needs every level.
One project, several outputs
An app is an interactive product with its own code, data, history, and releases. Slides are a presentation deliverable; other types serve other kinds of output. They can belong to one project without becoming one app or sharing an app database.
For example, a customer-onboarding project might connect an onboarding app, slides for a stakeholder review, and supporting material. Start with the shared outcome, then create the deliverables needed to achieve it. The types offered in your tenant determine which outputs you can create there.
Separate projects when ownership or objectives differ. Separate apps when they need independent behaviour, data, or release lifecycles.
Make visibility deliberate
Enterprise administrators can configure visibility and sharing at the relevant levels. Membership in an organisation or project should not be treated as permission to see all underlying work. Check the effective permissions for the intended audience.
See Your enterprise, your rules for internal visibility, collaboration, external sharing, and publishing controls.
Separate funding from budgets
Enterprise spending requirements may apply across an organisation, within a workspace, or to an individual project. A shared workspace credit balance is the funding source; it does not by itself express every spending limit your organisation needs.
Agree on budget ownership and allocation independently of where people sign in or apps are grouped. See Plans, credits, and usage for the current controls and the scope to confirm for an enterprise rollout.
Separate platform access from app access
People who build in Ahamo and people who use a generated app are different audiences. Being a workspace member does not define who should see private records in an app.
Define those app access rules explicitly and test them with separate accounts. See security and data review.
Check context before acting
Confirm the workspace before starting a build or changing a plan. Confirm the app and environment before inspecting data or publishing.
Switching workspaces does not move apps or transfer credits.
Next: Create and switch workspaces.