# Manage an organization and projects > Keep customer data separated by project and manage organization access safely. Canonical page: https://anectico.com/docs/manage/workspace-and-projects/ An Anectico organization is the team and billing boundary. Projects separate application data inside that organization. Choose a project before investigating or configuring anything; the current project in the header controls most dashboard queries. ## Create and choose projects Open **Settings → Projects** to create a project with a stable name and slug. Use separate projects when data needs a real access or lifecycle boundary. Use the `environment` field within one project for production, staging, and development when the same application should remain searchable as one system. If project creation reports that setup is temporarily unavailable, wait and retry. After a timeout or lost response, refresh the project list before retrying so you can check whether creation already succeeded. Creating again with an existing slug returns a conflict. Project controls follow the signed-in principal's exact permissions. `projects:read` returns the project list and any single project's record, and is available to every role, which is what keeps the header selector and Settings populated; `projects:write` additionally exposes create and edit actions, while `projects:delete` separately exposes deletion. Without either write capability, Settings keeps the project list visible in a clearly read-only state and the header does not offer a creation dialog. An API key with no `projects:read` cannot list projects at all — give an ingestion-only key its project at mint time instead. A newly provisioned organization with `projects:write` can still create its first project from the header when its project list is empty. The active-project selector stays in the dashboard header on desktop, tablet, and mobile. On a phone, the trigger is narrower and truncates long names, but opening it still shows the complete project list. After creating a project: 1. select it in the dashboard header; 2. create or scope an application key with the required telemetry permissions; 3. configure every participating SDK or collector with that key; and 4. send a test signal before rolling out broadly. An organization must keep at least one project. Deleting a project is destructive; verify which SDKs, alerts, API keys, dashboards, and automations refer to it first. Cleanup runs in the background after project or organization deletion. Once the tenant deletion boundary is applied, matching product events, logs, traces, metrics, agent events, error events, error groups, and evaluation results stay hidden from telemetry reads, including organization-wide searches and earlier queued deliveries that arrive late. Deleting one project preserves sibling projects. Read suppression and physical storage reclamation are separate; a successful project-delete response does not mean every background cleanup has already finished. Project-scoped credentials are pinned to their signed project for project reads, updates, deletion, and project configuration. Passing a different `project_id` cannot widen access. Exact project lookups also return the same not-found response for a missing project and a project outside the credential's organization, so callers cannot use the endpoint to discover another tenant's IDs. ## Invite and administer members Open **Settings → Team** to review everyone who can access the current organization and confirm each person's role. The signed-in account is marked **You**, which helps catch an unexpected organization or role before changing configuration. Owners and admins can invite a teammate from this page by entering the person's email and choosing Admin, Member, Developer, or Viewer. Anectico emails a single-use acceptance link to that exact address and shows the invitation as pending until it is accepted or revoked. The invitee signs in with the invited email before accepting. Acceptance switches that browser to the shared organization and clears cached data from the invitee's previous personal workspace; the personal workspace itself is not deleted or merged. The same invitation operations are available through the Anectico CLI: ```bash anectico invitations create engineer@example.com --role ROLE_MEMBER anectico invitations list anectico members list anectico members set-role ROLE_ADMIN anectico members remove --yes ``` An emailed invitation link resumes after you sign in. Anectico keeps the return path in an HttpOnly, same-origin cookie for the login round trip and removes the invitation token from the address bar once the acceptance page loads. Only grant an admin role to people who need organization configuration or destructive capabilities. Removing a member does not rotate credentials they created; review and revoke unnecessary API keys separately. A removal takes effect immediately and permanently: the moment the request succeeds, that person has lost access to the organization. The member list is rebuilt a moment behind it, so a list reloaded right after a removal may still show the person for a second or two. Reload again rather than removing them a second time — the first removal is already final, and a repeat only reports that there is no longer such a member. Current organization roles are **Owner**, **Admin**, **Member**, **Developer**, and **Viewer**. Owners and admins receive organization configuration and destructive permissions. Members and developers receive the collaborative/operator surface, including self-service API-key management. Viewer is a read-only security boundary: viewers can inspect telemetry, dashboards, settings, and usage but cannot ingest, acknowledge, respond, edit, create, revoke, or delete product state. Viewer is also the one role that sees less telemetry, not just fewer buttons: it can list session recordings, agent runs and customers, and cannot play a recording back, open an agent run's transcript, or read a customer's profile properties. Choose Member for anyone who needs recorded customer content; see [Permissions and scopes](/docs/reference/permissions#what-the-viewer-role-can-see). The Team page requires confirmation before changing another member's role, and role changes take effect in a newly issued or refreshed session token. Existing API keys keep their stored scopes and must be reviewed or revoked separately after a demotion. ## Verify context before acting Open **Settings → Account** to confirm the signed-in email, organization, and role. In the CLI, use `anectico projects list` and `anectico projects use ` before a write. For automation, prefer a project-scoped key rather than relying on the operator to remember a project flag. Owners and admins can open **Settings → Audit** to inspect the organization audit trail. The view shows actor, action, resource, result, time, and allowlisted target context — including, for an action taken by an agent, the tool it used and that it arrived over the agent interface. It deliberately omits network identifiers, user agents, and arbitrary metadata. The **result** column, and the filter beside it, distinguishes a change that was applied from one that was refused, previewed, throttled or errored. Filter on `denied` to see what a credential tried and was not allowed to do; see [Review what the agent did](/docs/reference/credential-revocation#review-what-the-agent-did) for the full vocabulary. Members, developers, and viewers do not receive `audit:read` by default. For API-key lifecycle events, the verified user or API-key actor is shown separately from the key being created, renamed, scope-edited, or revoked. If an older event did not record an actor, the view says the actor is unknown rather than guessing from the target. - [Authentication and API keys](/docs/reference/authentication) - [Permissions and safe actions](/docs/agents/permissions-and-safety)