Project, organization and account
An account is one person, an organization is a group of accounts, and a project is one stable identity that an organization owns and that Workspace, Delegate and CDN share. A project is not a repository, a package or an application.
- Availability: Experimental
- Evidence: Recorded run
- Explanation
The problem this solves
Your team has a repository in Delegate, two applications in CDN and source it develops in Workspace. Are those one project or four? Who owns them when the person who created them leaves? These three words answer that.
The three in plain language
| What it is | Where it lives | Identified by | |
|---|---|---|---|
| Account | You: one person, recognized by the sign-in methods you attached | Beyond Accounts | acc_… |
| Organization | A group of accounts, each with a role: Owner, Administrator, Developer or Viewer | Beyond Accounts | org_… |
| Project | One piece of work that an organization owns, with a name for people and an identity for the products | Beyond Projects | prj_ followed by 24 lowercase hexadecimal characters |
A project always belongs to exactly one organization, never to a person. When its creator leaves the organization, the project stays with the organization.
What a project is not
| A project is not | Because |
|---|---|
| A repository | Delegate attaches repositories to a project, and one project can have several |
| A package | A project's source is a workspace that can hold several packages. See Develop with Beyond |
| A CDN application | One project can have several applications, each with its own releases |
| A Delegate project or a Delegate workspace | Those are Delegate's own records, with their own people and permissions. In a Delegate installation that is connected to Beyond Projects they can be attached to a Beyond project, and they keep their own identifiers |
The products keep their records and refer to the project by its identity. They are linked by identity only, never by name: two things called "Storefront" are not the same project until someone links them explicitly. One product record belongs to at most one project.
What follows from what, and what does not
- Being a member of the organization lets you see its projects in Beyond Projects. What else you can do there depends on your role.
- A role in the organization is not access to a product's resources. Workspace, Delegate and CDN each decide that for themselves, every time you arrive. See Identity and resource permissions.
- Membership is not Workspace development access. Development is closed, and Beyond grants it per organization and per member.
- A link to a project is not a permission. It carries the identity and nothing else.
- Renaming a project changes nothing that refers to it, because everything refers to the identity.
- Archiving or deleting a project in Beyond Projects deletes nothing in the products.
- Integrating code into a project is not publishing it: see Preview, integration and publication are different things.
More detail
- The identity is opaque: it says nothing about the name, the organization or the date. It is never reused.
- A project has a state: Active, Archived or Deleted, the last one recoverable for a period the installation configures.
- A project created from a template records the template name, version and exact source revision it came from, once. A project registered for existing work records that it was adopted instead.
- In a Delegate installation that is connected to Beyond Projects, a workspace administrator can link the Delegate workspace to one organization, so that its projects can be attached to that organization's Beyond projects. The link gives nobody a seat or a role: see Use Delegate with a Beyond project. Without that connection, nothing relates an organization to a Delegate workspace.
- For the difference between an organization and a product's own workspace, see Account, organization and product workspace.
Next action
Sign in to Beyond Projects, or read what Beyond Projects is.