Plan work and deliver projects

From a clear plan to a recorded delivery#

Create a project with a concrete outcome, an explicit audience, a timezone and an optional starting template. Give current workspace members appropriate project roles. Add tasks and milestones, then follow actual task completion and record delivery decisions deliberately.

Projects and To Do use the same task records. A checklist tick, a task’s final status, a manager’s milestone completion, customer acceptance, an issued invoice and actual payment are separate facts. One does not silently establish another.

This release covers planning, list and board views, scoped project membership, milestones, delivery originals, retained activity, archive/reopen and optional whole milestone invoicing. Project time is recorded through the separately installed Timesheets & Time Billing app, using the same project/task identity. Projects itself does not provide payroll, resource capacity, budgets, predictive risk, Gantt dependencies, guest customer access or automatic bank payments.

Set up Projects with the owner’s policy#

Install and configure To Do first. Projects needs its current task workflow and valid app allowance. If a prerequisite is missing, install it before continuing. Changing profiles does not move projects, tasks, licences, staff or invoices between workspaces.

Choose who may create projects, the default private or workspace audience, an IANA timezone and a starting template. Review the actual To Do columns shown. Project boards use those columns; they do not create a second workflow with different completion meanings.

Private is the considered default. Choose workspace visibility only for information suitable for everyone currently in that workspace. Personal projects stay in the personal workspace; corporate authority does not open unrelated personal work.

Choose exactly who may read the plan#

A private project is readable only by its explicit project members. Being a workspace owner or administrator does not automatically open someone else’s private project. A workspace-audience project may be read by all current workspace members, including read-only staff.

The project description, tasks, task details, assignees, checklist, milestones, delivery originals and nonfinancial activity follow the project audience in Projects and ordinary To Do. Financial agreements, amounts and invoice links require separate current financial permissions.

Changing an existing audience requires a current server review and deliberate confirmation. Review the number of tasks and milestones affected. A stale review is rejected if the relevant project facts changed. Reducing the audience does not erase information someone legitimately accessed earlier.

Do not place confidential payroll, medical, household or internal financial information in shared task descriptions or delivery files. Use the intended workspace and audience before adding sensitive material. External customer records are not invitations or authenticated project memberships.

Review project roles within workspace permissions#

Owners and managers manage planning and membership within their current app permissions. Contributors work on permitted tasks. Viewers read the plan. A project grant cannot exceed a current workspace role: a workspace viewer cannot become a project writer.

Financial viewing and milestone billing are deliberate additional grants, subject to current corporate Invoicing access. A planning manager without financial authority cannot see or overwrite hidden financial grants. Existing hidden grants are retained during permitted planning-role edits; removing a member deliberately revokes that person’s private project access.

Save the reviewed complete member list together. Current versions prevent an old form from silently replacing newer membership. Transfer ownership to another eligible project owner before removing the final active owner. Staff removal or permission revocation takes effect across Projects and direct To Do access.

An assignee must be a current eligible contributor for this project. Offboarding retains the historical assignment instead of silently deleting it. Choose a new eligible person or explicitly clear the assignment when editing. An assignment or a named milestone owner is not an external customer grant.

Preview a useful starting template#

Blank starts without tasks or milestones. Simple delivery creates planning and delivery milestones with a small set of practical tasks. Client service creates scope, preparation and handover work without claiming customer acceptance or payment.

Preview the actual milestone and task titles before creating the project. The starter tasks become ordinary protected To Do records in the project’s dedicated list. They can be adapted under the same task permissions. Templates are planning conveniences, not certifications or legal checklists.

Work in a list or board without duplicating task truth#

Project tasks live in the project’s dedicated To Do list. Creating, editing or completing one updates the same task in either app. Existing unrelated personal or other project tasks cannot be attached or moved into the project as a shortcut to sharing them.

Use the real configured status columns, priority, exact due time, eligible assignee and checklist. The final To Do column controls task completion. Moving a task back retains the recorded history but makes its current completion state incomplete again.

List and board filters and pagination show the current bounded result page. Column counts describe tasks on that page; the project’s completion and overdue summary uses all authorized project tasks. A filtered board does not silently claim to show every task.

Link a task already in this project to at most one active milestone. A milestone supports up to 500 active linked tasks; each linking action accepts up to 100 selections. Releasing a mistaken planning link requires a reason and retains its history; it does not delete the task. Tasks retained as milestone evidence cannot simply be deleted. An outdated task version is rejected instead of overwriting a colleague’s newer work.

Use project calendar dates and precise due times#

Project start/due dates and milestone planned/actual completion dates are literal calendar dates in the declared project timezone. They do not shift a day because a browser runs in a different country. Task due dates include an exact clock time and are stored as instants.

The task editor labels the project IANA timezone explicitly. It converts your entered local clock time to an exact instant. A time skipped by a daylight-saving clock change must be changed; the editor does not silently shift it. If a clock time occurs twice, deliberately choose the earlier or later occurrence and its UTC offset.

An unchanged task due time retains its exact original instant. Readouts show the declared project zone and offset where appropriate. Actual milestone delivery dates cannot be future dates. Planned due dates do not establish actual delivery.

Record delivery as a deliberate manager decision#

Plan a milestone with a clear expected result, an optional responsible project member and a planned calendar date. Link relevant tasks from this same project. The completed/linked task count reflects actual current task state.

Start the milestone when the work begins. On completion, record the actual completion date, delivery or handover reference, reason/context and any selected delivery originals. If linked tasks are unfinished, explicitly review and acknowledge them. The decision does not change their status.

A milestone decision records the responsible operator’s internal delivery judgment. It is not a verified customer signature, statutory compliance certificate, invoice issuance or proof of payment. Cancellation and reopening retain prior decisions. Reopening a completed milestone preserves the original completion record and its originals.

A project placed on hold still retains its readable work. A completed or archived project must be reopened before planning/delivery changes. Current permissions and versions are checked again when recording a decision.

Retain delivery originals in the intended project audience#

Attach only relevant PDF, JPEG, PNG, WebP, TXT or CSV delivery originals, within the displayed upload and workspace storage limits. Files are downloads, not automatically parsed or rendered as trusted instructions. Do not upload bank-proof originals or private financial notes into this shared delivery area.

Permitted project writers may attach unused planning originals to an open milestone. A permitted manager deliberately selects up to ten originals for an actual completion decision. Selected originals are retained with that decision and cannot be silently replaced or removed.

Current project access is required for metadata and downloads, including copied file URLs. Generic workspace Files access does not bypass this boundary. File fingerprints help verify retained bytes; they do not prove the truth, author identity or legal adequacy of a document.

Pause, complete, archive and reopen a project#

On hold records an intentional pause; resume returns to active work. Project completion is a manager planning decision with a reason and an explicit unfinished-task review where needed. It does not automatically complete tasks or assert that every contractual obligation has been met.

Archive retains the project’s work, delivery decisions, originals and financial source history. Reopen deliberately restores the planning workflow while preserving earlier decisions. No lifecycle action deletes an issued invoice or creates another billing entitlement.

Connect whole milestone billing only when deliberately needed#

Optional milestone billing is business-only and needs configured, licensed Invoicing, an explicitly enabled project and current financial viewing/billing grants. Personal projects do not infer a corporate seller or transfer business invoices when profiles change.

Prepare an active business customer, a commercial title, explicitly public customer notes/terms and exact original billing lines. Each line has quantity one, a decimal unit price, discount and the declared Invoicing tax interpretation. Review the saved server-calculated seller/customer identity, currency and total before approving and freezing the agreement.

Public agreement notes and terms are intended for the customer invoice. Internal project/task descriptions and delivery notes are not copied into it. Operational project readers receive no hidden amounts, financial counts, terms or invoice links.

An approved agreement stays frozen independently of later planning edits. Changed seller/customer identity, country, currency or tax interpretation must be resolved before new trade; a live settings change does not silently rewrite an approved agreement. Whole milestone invoicing does not offer arbitrary percentages or partial quantities.

Create, issue and follow the source-owned invoice separately#

After an authorized manager records milestone completion and the exact agreement is approved, deliberately create one complete source-owned invoice draft. Creating the draft is separate from issuing it. Repeating the same request does not create another full invoice.

Issue through Projects using the normal Invoicing country, numbering, authority, payment and accounting safeguards. A government or compliance block remains a block. Generic invoice editing cannot rewrite the project source’s customer, amounts or whole billing terms. Service milestone quantities are not stock dispatch instructions.

A never-issued draft may be discarded only when the source and Invoicing checks permit it, with a retained reason. An issued, paid, credited or authority-locked source does not become available for another full invoice merely through retry, project archive or a credit.

The invoice’s status and balance come from Invoicing. Record real payments or permitted credits there under its existing rules. Delivery remains separate; recording payment does not complete tasks, and reopening work does not reverse an invoice. No customer email or bearer payment link is automatically published in a task feed.

Apply country-specific obligations at the correct boundary#

Projects is general planning and internal delivery, not a statutory accounting, payroll or regulated project certification. Use the declared business country for optional invoicing. Interface language, geolocation and subscription currency do not determine registration or tax obligations.

Country-specific invoice and authority restrictions belong to Invoicing’s reviewed workflow. Enabling Projects does not establish ZATCA, FBR, ATO or any other authority certification or live integration. Review the country/recordkeeping guide and applicable professional advice before regulated claims.

Choose suitable audience, minimization and retention for the work and originals. The organization remains responsible for its privacy notices, employment/customer obligations, legal holds and applicable retention requirements.

Official references: Business country and recordkeeping review ↗

Review scoped records, exports and safe recovery#

Activity retains operator names, reasons and relevant project decisions within current access. Private financial activity is excluded from operational views. Changes append retained decisions rather than rewriting an earlier delivery fact.

Print shows the project task and milestone result pages indicated, with the project timezone and explicit planning context. CSV exports authorized project task facts under the chosen filters, up to 5,000 tasks; they are not a financial statement or legal delivery certificate.

If an action reports a stale version, keep your intended changes, reload the current project and review the differences before submitting a new decision. A missing permission, changed licence, expired demo or revoked membership cannot be bypassed by a retained browser form or file URL. Never repeat a real bank payment to resolve a source-display error.