Client projects
A client project separates an independent line of work for one client from the general client history. It has its own description and plan, while tasks, opportunities, files, discussions, and external access stay in one traceable context.
Open the catalog from Client projects and select a project to open its workspace. Available records and actions depend on your permissions and the client-context policy.
The catalog is available at /client-projects, and you can open a specific project directly at /client-projects/:clientProjectId. The card content and available actions depend on your permissions.
The project catalog
The catalog shows projects in pages. Each row or card shows the name, kind, status, and last-updated date. Select the name to open the project workspace.
Filters include:
- name search, applied after a short pause rather than once per keystroke;
- All or Mine — Mine keeps projects where you are the owner;
- status: active, inactive, or archived;
- kind: division, branch, department, brand, site, program, client project, or other;
- client — an account or contact linked to the project;
- Include archived — adds archived records to the result.
Filters narrow the project list. If the result is empty, reset narrow conditions. Long lists use Show more or load the next page automatically; the count can be exact or a lower bound while the full count is still being calculated.
On /client-projects, select New project, or open the form directly at /client-projects?create=1. Name and client are required; type defaults to Client project, status to Active, and tags are optional comma-separated values. A client passed from a filter or entry point is prefilled but remains editable; the registry form has no separate owner or parent-project field. With no name or client, the form shows an inline error and sends no request; controls are disabled while creation is in progress. A create failure stays in the modal for review and retry; on success, the portal opens /client-projects/:clientProjectId. If the selected locale is not fully translated yet, some labels, states, or errors may temporarily appear in English or mixed language; data and access rules do not change.
Catalog states
- a skeleton is shown while loading;
- use Retry after a read error;
- an empty catalog explains that no projects exist yet;
- an empty filtered result offers to reset the filters;
- the footer confirms when the end of the list is reached.
An empty result does not prove that the work is absent: check filters, permissions, and the selected client. Archived projects are hidden by default.
The project workspace
Check the name, kind, status, linked client, and owner at the top. An archived project is kept for history and should not receive new work; its record may be read-only.
The overview contains:
- description — agreements and context a new participant should read;
- project checklist — groups and items, including nested items and completion marks;
- start and due dates — planned project dates;
- owner — the person responsible for project integrity.
The checklist is a plan and set of checkpoints, not a list of assigned tasks. Checking an item does not complete a task or notify an assignee. When someone needs an owner, due date, and acceptance, create a task in the Tasks tab.
Changing the owner
In the settings panel you can choose a different owner when you have transfer ownership permission and the project is not archived. The staff roster loads when you open this picker. The selection is saved inline immediately; wait for the saving indicator and verify the refreshed project summary. Without the capability, or for an archived project, the field stays read-only. A save error does not change the current owner; check access and project status before trying again.
In project settings, you can edit status, type, parent project, and tags. Parent choices are limited to non-archived projects for the same client; a project from another client or an archived record cannot be selected. Each field saves inline; a failed save leaves the current value unchanged and shows a failure toast with a retry path. Archiving requires confirmation; after confirmation the project is read-only and cannot receive new tasks. Ask the project owner or an administrator to restore it.
Editing the checklist
In edit mode you can create, rename, move, and delete a group or item, nest an item, and return it to the top level. Long checklists are paged; open a group to load its items. An empty group remains a valid drop target.
If someone changed the project first, the portal makes one fresh-revision retry. If the conflict remains, the action was not applied: reread the current data and retry yourself without overwriting the other change. Deleting an item with children may take time; wait for the structure to refresh.
Press Enter to add an item: the row appears immediately while create requests are sent in sequence. On a short ungrouped list, the grouping control may be hidden; it appears once the list is large enough or after the first group exists. On touch screens, row actions are grouped in one … menu instead of several always-visible buttons. Deleting an item removes it immediately and offers a short Undo window; after that window the server may show it as pending while child items are reparented. If deletion fails, the item returns to its previous position. Treat the final refresh—not the initial disappearance—as confirmation.
Dates, description, and archive
The start date cannot be after the due date. An invalid range is rejected; correct both dates and retry. Saving the description or checklist requires write permission.
After the project content was connected to the shared locale tree, 26 visible overview, files, checklist, and parameter keys are translated for all nine locales. Full parity is not reached: the guard baseline still records inherited base-language keys — de 104, zh 102, es 102, fr 103, ar 70, kk 102, and ky 102. In the activity feed, a server-provided event sentence may remain Russian regardless of the interface language; the project name inside it is data, not localization proof. For same-locale review, check visible labels and event text rather than htmlLang alone; screenshot/evidence remains source-gated until parity is complete.
Turn on the editing switch to open the description in the rich-text editor. Its formatting toolbar offers headings, lists, emphasis, links, and other available actions. Changes are saved automatically when focus leaves the editor; press Escape to discard the draft and restore the last saved description. To mention a colleague, type @, use ArrowUp/ArrowDown to choose a suggestion, and press Enter; Escape closes the mention list, or cancels editing when the list is not open. When focus leaves the editor, a selection started in surrounding page text remains intact.
While editing, you can paste an image from the clipboard; the portal uploads it and adds an image block to the draft. Autosave on blur waits for the pending upload; if the upload fails, an error is shown and the image is not added.
Before archiving, move or finish open tasks, opportunities, and commitments. Do not archive to hide a disputed history. Ask the owner or administrator to restore an archived project, then verify access before resuming work.
Tabs and related material
The workspace connects:
- Tasks — execution with owners, dates, and acceptance;
- Opportunities — client outcomes in the right pipeline;
- Files and links — working material and external addresses;
- Relations — links to other records;
- Discussions and conversations — decisions and communication in context;
- Templates and Settings; the Settings view also shows the project's access panel and members.
Create work from the project so its client and project links are retained. Before adding a file, discussion, or external participant, open Settings and check the access panel: client projects have no separate Access tab, and the project context does not make internal material public. Extranet is not a client-project tab; configure the external perimeter from the client workspace or the dedicated extranet guidance.
Permissions and safety
Project permissions can grant read, write, manage, or no access. A missing edit button is an expected policy result, not a reason to bypass the restriction. Do not put secrets, tokens, or unnecessary personal data in descriptions, checklist titles, filenames, or public links.
Use synthetic clients and anonymized names in demos. Do not put real secrets, payment details, or unnecessary personal data in a project. Before sharing project material, check that its text and data do not reveal information about a real client.
For reproducible workspace checks, use the canonical pair: client Demo Client North and client project Client rollout — demo. Do not replace the project with Rebranding — demo: that name is reserved for the synthetic CRM opportunity. Do not use real data or raw IDs.
Completion check
- The project has the correct client, kind, and owner.
- Active tasks and opportunities are in the project tabs, not lost in a general list.
- The checklist expresses the plan and is not used as a substitute for tasks.
- Dates form a valid range, and archived projects do not receive new work.
- Files, discussions, the Settings access panel, and the external perimeter match the role and privacy policy.
Client-filter and timeline states
The client filter opens a separate search over accounts and contacts. You can search with the keyboard, choose with Enter or a click, close with Escape or an outside click, and clear the selected client. A client-search error is not an empty project catalog: retry or reset the filter.
A client-project workspace can expose Activity, Tasks, Opportunities, Commitments, Entitlements, Fulfillment, Billing, Files, Documents, Links, Relations, Conversations, Discussions, Templates, and Settings. Tabs open as needed; empty or unauthorized sections may remain under More. The activity timeline can temporarily show a preparing state with Retry. This does not mean that the project or its other data is lost.
Even when the project file projection is preparing or failed, attaching a file remains a separate available operation. Verify the result by names and counts; a batch upload reports successful files and failed names separately. A detach confirmation refers to the operation even when the list cannot yet show the new state.