Change or delete an organization or project

Update a name, slug, or logo from Settings. Delete an organization or project only when you understand the permanent effect on its dependent work.

Time: About 2 minutes to update a resource; deletion is permanent.

• Open the organization or project you need to change.
• Organization owners and admins can update organization settings. Only an owner can delete an organization.
• Organization owners, organization admins, and project leads can update an accessible project's settings. Only an organization owner or admin can delete a project.
• Members do not have access to organization or project settings.
• Changing a slug changes the corresponding alterac.ai path. Share the new path with people who use the old one.

1. Open the organization or project, then select Settings.
2. Change the name, slug, or logo.
3. Select Save changes.

The updated name and logo appear in the dashboard. If you changed the slug, the settings page continues at the new path.

From Project Settings, open Review branch guidance. Default review branch comment shows the effective Markdown used to start a Check and update review branch request. Organization owners, organization admins, and project leads with project access can change it; members cannot manage this setting.

1. Edit Default review branch comment with the guidance you want reviewers to start from. Use Markdown headings and lists, and preview it before saving.
2. Select Save comment. Empty or whitespace-only comments cannot be saved.

The platform default applies until you save a project comment. Select Restore platform default to remove the project comment and use the platform guidance again. A failed save keeps your entered comment available for retry and leaves the confirmed default unchanged.

Both branch-check entry points start with this effective default, and reviewers can edit the comment for each request. Changing the project default affects newly opened dialogs. It does not replace a draft in an already-open dialog or change saved review comments, earlier work-run context, or review history.

From Project Settings, use Sprints and Milestones to enable each feature independently. Both start enabled. Team Leads and organization owners or admins with project access can save these settings; ordinary members cannot manage them.

1. Change Enable Sprints, Enable Milestones, or both.
2. When Sprints are enabled, set Default Sprint duration (days) to a whole number from 1 to 28. The initial default is 14 organization-local calendar days. Changing the default leaves existing Sprint dates unchanged.
3. Select Save scheduling settings. Navigation changes after the save succeeds.

Turning a feature off hides its navigation and ordinary entry points while keeping its stored records and history. It does not close records, clear membership, reset tasks, or change the other feature, Plans, or Metrics. Re-enabling restores the feature's availability with its stored state. The Sprint duration stays stored while its control is hidden.

Choose the configuration that fits the project:

Prepare and manage Sprints owns Sprint preparation, the daily page, completion, and retained history. Create and manage Milestones owns outcome preparation, browser lifecycle, and retained history. Task forms support independent membership and classified changes. The CLI task workflow covers delivered assignment and disabled-feature recovery, and the Milestone command reference covers metadata commands.

A direct visit to a disabled feature shows an unavailable state. People who can manage the project can open Project Settings from that state; members are directed to ask a Team Lead. Re-enable the feature before changing its membership or lifecycle. Browser estimate edits that affect retained Current history still collect a neutral planning-history intent; see the task workflow for the separate CLI boundaries.

If another person changes these settings while you are editing, select Reload settings to load the confirmed values before making your change again. A failed save keeps your draft available for retry and leaves confirmed navigation unchanged.

Prepare and manage Sprints owns Sprint creation, planned start and end dates, the reference-Sprint end helper, metadata editing, and the current browser lifecycle boundary.

Read the Sprint Horizon for date context, corrected opening-plan totals, and retained Complete values.

Read Sprint progress for paired task-count and Size charts, metric eligibility, and exact values.

Use the Sprint Team Pulse to inspect per-person work, Unassigned tasks, and the six overall state cards.

Manage Sprint tasks for membership, explicit Correction/Scope change, retained outcomes, and recovery.

Complete a Sprint and correct its history for manual effective times, unfinished-work effects, retained corrections, and guarded reopening.

Organization owners and admins can choose whether new organization members automatically become Team Members in every project. Open Organization Settings, change the automatic project access setting, and save your changes.

The setting is enabled by default and applies only when you add a future organization Member. Changing it does not add current members to projects or remove existing project access. When automatic project access is turned off, add each organization member to the projects they need from the project's Members page. Organization owners and admins still have inherited access to every project, and making someone a Team Lead remains a project-level role change.

An organization owner or admin can open Organization Settings, find Organization time zone beside Working hours, search for a zone such as America/New_York, and select Save time zone. You can save it without configuring working hours.

Working hours and Sprint/Milestone dates use this shared setting. Sprint and Milestone pages, history, and date/time dialogs show the current organization zone beside their dates, including for older records. Your computer's zone does not change the view. Saving a new zone refreshes planning in the current session.

Changing the zone changes how a saved moment is displayed, not when it happened. For example, the same instant can appear as an evening in New York and the following day in UTC. Existing planned boundaries, task outcomes, and saved history are preserved. Reviewing a date without changing it also preserves its original instant. If you deliberately edit a date or time, your new value is interpreted in the current organization zone.

The organization working-hours schedule is used when Metrics calculates working-hours human review time. It does not change task completion or AI work time.

Organization owners and admins can configure one working-hours calendar for the organization from the Working hours section of Organization Settings. First save the organization time zone above, then select every active weekday, choose one local start and end time for each selected day, and save the calendar. The working-hours form shows the same organization zone and its current UTC offset, with a link to change it; the standard time selectors offer 15-minute intervals.

The time zone and weekday intervals belong to the organization, so changing a viewer's local time zone does not change the configured schedule. Nights, inactive days, and the portions of a working day outside its configured interval are outside the calendar. The calendar does not include public holidays, time off, split shifts, individual schedules, or project overrides.

Working intervals include their start and exclude their end. During a daylight-saving change, a local boundary that does not exist moves forward to the first valid local instant. When a local boundary occurs twice, alterac.ai uses the earlier occurrence for a start and the later occurrence for an end. Review intervals are intersected in UTC so the result cannot become negative or count the same instant twice.

Until an owner or admin saves a valid time zone and at least one active day, the organization has no working-hours calendar. alterac.ai does not invent a default schedule.

Owners and admins can select Remove working hours and confirm the change to unset the calendar. This preserves the organization time zone and stored review intervals, but working-hours human review time becomes unavailable until a new calendar is saved.

1. Open Settings for the resource.
2. In the delete section, select Delete organization or Delete project.
3. Type the displayed resource name exactly to confirm.
4. Select the final delete action.

Deletion is permanent and cannot be undone. Deleting an organization removes the organization, its projects, memberships, and dependent dashboard data. Deleting a project removes that project and its dependent dashboard data.

Organization Settings also contains the coding-agent policy for the organization's projects. It controls which organization, project, and personal coding-agent definitions can be used in those projects. Configure that policy separately from the organization and project details on this page.

Next, use Create organizations and projects to create another workspace, or use Manage members and roles to update access.