# Projects > Organize Temporal Cloud resources including Namespaces and Nexus Endpoints around your organizational structure > **Pre-release** Projects are an organizational layer within a Temporal Cloud Account that groups related resources into a single operational boundary. With Projects, you can organize Namespaces, Nexus endpoints, and Connectivity Rules around how your organization operates: by team, environment, service, or business unit. Projects make it easier to delegate ownership, manage access at scale, and organize resources without creating additional Cloud Accounts. As your organization grows, Projects help align your Temporal Cloud resources with your organizational structure while reducing operational overhead. Projects are for organization and authorization. They don't change how Workflows execute inside a Namespace. ## Default Project and Project names Every Temporal Cloud Account includes a Default Project. Existing Accounts receive a Default Project when Projects are enabled, and new Accounts are created with one automatically. The Default Project is not a special type of Project. It behaves like any other Project for managing resources. The only difference between the Default Project and any Projects you create is that the Default Project is created for you. For existing Accounts, all existing resources are automatically placed in the Default Project. All permission resources remain unchanged. For new Accounts, the Default Project is created automatically. New resources are automatically placed in the Default Project unless you specify otherwise. If you don't need the organizational boundaries offered by Projects, continue to use the Default Project for all your resources. You can always create a new Project later if you need it. All Projects are identified by immutable IDs, and by display names, which can be edited. Namespaces cannot be moved between Projects currently, meaning all existing Namespaces will exist in the Default Project. You can create a new Project and place a new Namespace in that Project. For limitations on the number of Projects per Account and number of resources per Project, see [Project-level limitations](/cloud/limits#project-level). ## Create a new Project Create a Project when a set of resources has a distinct owner or access model, separate from the Default Project. A good Project represents a stable ownership boundary, not just a folder. Start with one Project for a team or application with clear ownership. Add more only when needed. In the Temporal UI, click **Projects** at the top of the left navigation bar, under **Your Account**. You'll see a list of existing Projects associated with your Account. The first time you use Projects, you'll only see the Default Project in this list. Click the **Create Project** button to create a new Project. On the **Create Project** page that appears, give the Project a name (limited to 64 characters) and an optional description (limited to 255 characters). Click **Create** and you'll be taken to the page for your new Project. You cannot currently migrate resources from existing Projects to a new Project. Instead, from this page click **Create Namespace** to add a new Namespace to this Project. To add a Nexus Endpoint instead, click **Nexus Endpoints** in the left navigation and then click the **Create Nexus Endpoint** button. ## Add Resources to a Project To add a new Namespace to this Project, click **Namespaces** in the left navigation, and then click **Create Namespace** to add a new Namespace. To add a new Nexus Endpoint to this Project, click **Nexus Endpoints** in the left navigation, and then click **Create Nexus Endpoint** to add a new Nexus Endpoint. To add users, groups, and Service Accounts to the Project, click the **Project Identities** tab in the left navigation. The Project Identities page has three tabs, for Users, Service Accounts, and Groups. Click the **Manage Identities** button to add or remove users. The drop-down list on the left lists the available Project Roles. To add a user to a Role, select the Role from the drop-down, and then type the user's name or email in the search box. The user will be assigned to the Role and their details will appear in the list below. Click **Save** to save your changes, or **Cancel** to discard them. To modify an existing user's role, select the edit button in the list next to their current permission level. You can then update the user's permissions in this Project. Click the trash-can icon to remove Project permissions from that user. The Groups tab works the same way as the Users tab. To create a Project-scoped service account in this Project, click **Project Identities** in the left navigation. Then click the **Service Accounts** tab to create Project-scoped service account. Project-scoped Service Accounts are not created automatically with Project creation. Create them only when needed. Unlike an Account-scoped Service Account, a Project-scoped Service Account cannot access resources outside its Project. Use a Project-scoped Service Account when automation only needs access to one team's resources. If automation needs to work across multiple Projects, use an Account-scoped Service Account instead. A Project can contain multiple Project-scoped Service Accounts. Each Project-scoped Service Account belongs to exactly one Project. A Project-scoped Service Account cannot be moved to another Project after it is created. Project-scoped Service Accounts count toward the Project's Service Account limit. A Project cannot be deleted while it contains Project-scoped Service Accounts. API keys created for the Service Account inherit only that Service Account's permissions. Deleting a Project-scoped Service Account also deletes its API keys. ## Project roles The following roles are available at the Project level for users, groups, and service accounts: - **Project Admin:** Complete access to the Project resource itself and all resources in it. - **Project Write:** Write access to all the Namespaces and other resources in a Project, but cannot add other users. - **Project Read:** Read-only access to all the resources in a Project, including viewing the actual contents of a Workflow. - **Project Contribute:** Can create new Namespaces, and list all Project resources, but without access to Workflow contents. - **Project List:** List-only access to metadata for all the resources in a Project, but without access to Workflow contents. - **Project Member:** Minimal Project-level access; used when a user already has explicit Namespace-level access and only needs to be represented at the Project level > **⚠️ Warning:** > Project Developer > > Project Developer is a compatibility role that is automatically inherited by users with the Account Developer role. It allows them to create Namespaces (and manage them) without automatically granting access to all existing Namespaces in the Project. This role cannot be assigned directly. For new role assignments, assign Project Write or Project Contribute as appropriate. > A principal automatically inherits a Project-level access from their Account-level role. For example, a Global Admin automatically inherits the Project Admin access for every Project in the Account. Project-level permissions are additive. Granting a Project-level role does not reduce permissions inherited from Account-level or Namespace-level roles. A principal's effective permissions are the union of all applicable Account-, Project-, and Namespace-level role assignments. ## Modify an existing Project To modify an existing Project, click **Project Settings** in the left navigation. The Project Settings page appears, with the General tab selected by default. Here, you can change the name or description of your Project. You can also access your Project's unique ID. You can copy the ID, but you can't change it. ## Delete a Project To delete a Project, click **Project Settings** in the left navigation and then click the **Delete Project** tab. Click the **Delete** button to permanently delete the Project. Use the **Deletion Prevention** slider to set the Deletion Protection flag for this Project. Once set, the Project can't be deleted unless the flag is deliberately disabled. A Project must be empty, meaning it contains zero Namespaces, to be deleted. An Account must always contain at least one Project. If the Account contains two or more Projects, you can delete the Default Project. If the Default Project is deleted, Temporal does not automatically designate a new Default Project. If the Default Project is deleted, API calls that do not specify a Project (by providing a Project ID) will fail. Projects support a delete protection flag, similar to Namespaces. When this flag is enabled, the Project cannot be deleted until the flag is disabled. This flag is enabled for the Default Project. The flag is disabled for any new Project created by a user. This flag is not inherited by the Namespaces within the Project. Namespace delete protection can be managed per-Namespace. If a Project is the only one remaining in an Account, that project cannot be deleted, regardless of the status of the Deletion Protection Flag.