Skip to main content

Manage a Subproject

After a subproject exists, you manage it from its detail page: edit its details, adjust ownership, map stock and amenities, and — importantly — assign subproject roles to the users who'll work on it.

Editing a subproject

  1. Open the subproject from the Subprojects list or from its parent project.
  2. Click Edit (requires the edit subproject permission).
  3. Update the header fields — name, type, location, area details, amenities, custom fields.
  4. Save. Validation runs on submit, exactly as it does on creation.

The subproject code is permanent. Partner holdings are changed through their own holdings action (below) so the change is captured for audit.

Updating partner holdings

Use the subproject's holdings action to change ownership. The familiar rule applies:

Holdings must sum to exactly 100%, and at least one managing partner is required.

Saving new holdings replaces the previous set; the change is blocked if the total isn't exactly 100.00% or if no managing partner is designated. See Validation rules.

Area, amenities, and stock mappings

From the detail page you can also:

  • Adjust the saleable / non-saleable area breakdown.
  • Add or remove amenities (and edit their custom fields).
  • Manage stock mappings — the project stock that supplies this subproject's land.

These feed the area accounting that units depend on, so keep them current as the development changes. For Layout subprojects, the SVG site map and its plot/amenity mapping are managed on the Layouts and SVG page.

Assigning subproject roles to users

This is one of the most important things you do on a subproject. While organization roles say who a user is across the whole company, subproject roles say what a user can do within this specific subproject — and they can only add permissions, never take them away.

From the subproject's user-role mappings section you can:

  1. See who is currently assigned to this subproject, with their subproject role and their org role for reference.
  2. Add a user and grant them a subproject-scoped role (for example, Sales Staff or Project Manager for this block only).
  3. Remove or change an assignment.

A user can hold multiple subproject roles across different subprojects. When they act on something inside this subproject, their org-role permissions and any subproject-role permissions are merged (union). For the full rules on how this works, who can assign roles, and the available subproject roles, see Subproject roles.

tip

Use subproject roles to give a salesperson access to just the layout they're selling, without granting them anything elsewhere. It keeps access tight and auditable.

Deleting a subproject — guardrails

A subproject is soft-deleted (hidden but retained for audit) and can only be removed when nothing depends on it. Deletion is blocked when the subproject still has units (or other downstream references). When blocked, you'll see a message naming what references it. The full rules are in Delete guardrails.

tip

If a subproject has units but you want it out of active use, retire it through its lifecycle rather than forcing a delete — the history stays intact.

See also