Workgroups and projects
A workgroup brings people and work objects together around a project, client, product, or internal initiative. The catalog and workspace are related but different: the catalog manages the card and membership; the workspace is where work happens.
Where to find it
- workgroup catalog:
/projects; - project workspace: open the selected project from the catalog;
- task creation from a project: use Create task in the workspace.
The catalog supports text search, reset, paging with Show more, and opening a project. Search is applied with Enter or the Search button. Active and archived states are shown on cards, but the catalog has no separate active/archive filter. Open a card to enter the selected project.
For a direct link, use /projects/:projectId; the list also accepts ?projectId= and may open the selected project card immediately. Access to the project and its actions is permission-controlled.
Create a project
Set the name, code, description, owner, theme, and optional project or Scrum markers. Decide whether it should be open and visible in the catalog, and choose the initial status. Do not put real addresses, contract numbers, tokens, private links, or internal identifiers in the name or code.
Status and visibility
Keep these states separate:
- open — the project accepts current work;
- visible — its card appears in the catalog available to the user;
- closed — new actions are restricted by policy;
- archived — history is retained, but the project is not for new work.
Visibility does not replace permissions. Membership, access policy, or a disabled module can hide a project even when its status is active.
Participants and roles
Catalog roles can be owner, moderator, member, or guest. Workspace settings may use owner, manager, member, or observer instead. Check the action hint on the current screen before assuming that role names or permissions match.
Before adding or removing a member, check the tasks, documents, links, and discussions they will see. Transfer ownership only to the person accountable for the project. In the members dialog, selecting the owner role requires the separate Allow ownership transfer opt-in. If it is unavailable, ask an administrator. Before removing a member, reassign active work and check the related objects; removal must not be used to hide history.
The Members dialog loads membership separately from the catalog. You can add a person, change a role, or remove a member; an empty roster has its own state. Actions are hidden or disabled when policy does not allow membership management. Deleting a project requires confirmation and refreshes the catalog only after success; keep the card and retry after a failed request.
Workspace tabs and context
The workspace can include Overview, Activity, Tasks, Files, Documents, Links, Relations, Discussions, Templates, and Settings. Tabs depend on rights and data; narrow screens move non-core items into More.
- Overview contains the owner, description, members, and key facts;
- Activity contains change history and events;
- Tasks contains work with the saved project context;
- Files and Documents contain working material and results;
- Relations and Discussions contain decisions and linked business objects;
- Settings contains membership, description, and workspace rules.
In the project workspace, turn on editing to open the description in a rich-text editor with headings, lists, emphasis, links, and other available actions. Changes save automatically when focus leaves the editor; Escape discards the draft and restores the last saved description. To mention a colleague, type @, choose a suggestion with the arrow keys, and press Enter; Escape closes the list, or cancels editing when it is not open. A clipboard image is uploaded and added to the draft as an image block; autosave waits for the upload, and a failure shows an error without adding the image—paste it again to retry. When focus leaves the editor, a selection started in surrounding page text remains intact.
Creating a task from the workspace preserves the project link and may preserve client or CRM context. After creation, verify that the task is in the intended project and has an accountable owner.
Version conflicts
Project edits protect against accidental overwrite. If another person saved first, the portal warns about a conflict instead of overwriting their change. In that case:
- do not retry the save blindly;
- reload the current project card;
- compare the changes and reapply only what you still need;
- save the new version and check the history.
Read, save, delete, and membership errors remain visible as a notice or toast. Do not treat a card disappearing after a failed request as a successful change: refresh the catalog and verify the actual state.
Safe documentation
Use synthetic projects, members, files, and links. Do not show real emails, phone numbers, client documents, private URLs, internal codes, or mixed-language labels. Money shown in examples must match the selected locale; omit money fields from money-free demonstrations.
Additional catalog and member states
Search applies after Enter or the Search button. The Members dialog loads membership separately, supports adding people, changing roles, and removing members, and has its own empty state. Actions are hidden or disabled without permission. Deletion requires confirmation and updates the catalog only after success; if an action fails, refresh the catalog and verify its actual state.
Related pages