Knowledge Base (Public)

What this is

Public-safe guidance for using Fast Project Hub. Internal details live in the Internal KB (requires login).

When to use it

• New users learning the platform.
• Project teams needing quick how-tos for modules.
• External users who have been invited and need orientation.

Table of contents

• Overall concept: see “Overall concept” below.
• Modules index: quick links to each module guide.
• What’s new: recent changes (public-safe).

Module index (short)

• Projects — create and manage project workspaces.
• Document Register — controlled documents and approvals.
• Inspections — checklists and evidence.
• Deviations & CAPA — nonconformities and corrective actions.
• QMS — quality actions, workflows, management reviews, release packages.
• HMS (Project) — project HSE control.
• HMS (Internal) — company-level internkontroll baseline.
• Compliance — obligations and controls (internal operations summarized safely).
• Roles & Access — how roles and access requests work.
• Diagrams/Builder — diagrams attached to documents.
• Project Cost — optional cost view.

Navigation

Use the module index or “What’s new” for the latest updates. For administrator details, refer to the Internal KB after login.

Overall concept

What this is

A unified workspace for projects, controlled documents, inspections, deviations/CAPA, QMS workflows, and HMS (health & safety), with protected evidence and audit trails.

When to use it

• Any project needing controlled documents, inspections, and actions.
• Teams preparing for audits or external deliveries.
• Organizations running QMS/HMS processes.

Key concepts (simple)

• Projects scope work, documents, inspections, and actions.
• Document Register controls files and approvals.
• Inspections capture evidence via checklists.
• Deviations/CAPA track issues and actions.
• QMS manages actions, reviews, and release packages.
• HMS manages health/safety at project and company level.

Step-by-step workflow

1. Create a project.
2. Seed the document register (optional template).
3. Run inspections and log deviations/CAPA.
4. Manage actions (assign, work, verify).
5. Use QMS/HMS dashboards for reviews and readiness.
6. Build release packages for approved sharing.

Common tasks (how-to)

• Upload a document version and request approval.
• Start an inspection and attach evidence.
• Log a deviation and assign actions.
• View dashboards for overdue items.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | View project data | Internal project members (external if invited) | Read access to allowed items. | | Upload/manage documents | Internal contributors/owners | Controlled via approvals. | | Run inspections | Assigned internal inspectors | Capture evidence securely. | | Raise/close actions | Internal users with project access | Verification step may need approver. | | Approve releases | Admin/owner roles | Internal approval before sharing. |

Evidence and traceability (high-level)

• All files are versioned in the Document Register with protected previews.
• Status changes and approvals are logged.
• Actions require verification where configured.

Good operating routine (weekly/monthly)

• Weekly: check overdue actions and reviews.
• Monthly: review document statuses and expiries.
• At kickoff: seed the register and HMS profile.
• Before release: confirm approvals and completeness.

FAQ (safe)

• **Can external users see internal notes?** No—internal notes stay internal.
• **Where are files stored?** In the Document Register with protected access.
• **Do I need HMS for every project?** Recommended for safety and compliance.

*For administrators: see Internal KB → Platform (requires login).*

Modules index

Quick links to each module guide (public-safe).

• Projects — workspace for documents, inspections, actions.
• Document Register — controlled documents and approvals.
• Inspections — checklists and evidence.
• Deviations & CAPA — nonconformities and corrective actions.
• QMS — quality actions, workflows, management reviews, release packages.
• HMS (Project) — project HSE control.
• HMS (Internal) — company internkontroll baseline.
• Compliance — obligations and controls overview.
• Roles & Access — roles and access requests.
• Diagrams/Builder — diagrams attached to documents.
• Project Cost — optional cost view.
• What’s new — public-safe changelog.

*For administrator details, use Internal KB after login.*

Projects

What this is

Workspaces that hold documents, inspections, deviations, actions, and HMS/QMS activities.

When to use it

Use a project whenever you need controlled documents, inspections, and actions tied to a specific delivery or scope.

Key concepts (simple)

• Dashboard with status cards.
• Document Register for controlled files.
• Optional project HMS profile.
• Members with roles (owner, co-owner, contributors, external viewers).

Step-by-step workflow

1. Create a project.
2. Seed the document register (optional template).
3. Add members and roles.
4. Upload/register documents and run inspections.
5. Track deviations/actions and HMS/QMS status.

Common tasks (how-to)

• Open the project dashboard.
• Seed the document register.
• Add members/roles.
• View HMS/QMS dashboards.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Create/manage project | Admin/Owner/Co-owner | Full control of the project. | | Contribute documents/inspections | Internal project members | Upload files, run inspections. | | View | Assigned internal users; invited externals | Read-only or limited actions. |

Evidence and traceability (high-level)

Documents and evidence are stored in the Document Register with version history; actions and status changes are logged.

Good operating routine (weekly/monthly)

• Weekly: check overdue actions/approvals.
• Monthly: review document and HMS/QMS statuses.
• Kickoff: seed register and HMS profile.

FAQ (safe)

• **Can external users upload?** Typically no; they are usually read-only unless granted.
• **Where are files stored?** In the protected Document Register.

For administrators: see Internal KB → Projects (requires login).

Document Register

What this is

Controlled list of project documents with version history, approvals, and protected previews.

When to use it

Use for any project-controlled file that needs traceability, approval, or sharing via release packages.

Key concepts (simple)

• Register entries (ID, title, type).
• Versions/files with approval status.
• Preview (PDF/image) where supported.
• Review cadence indicators (due soon/overdue/missing).

Step-by-step workflow

1. Create register entries (or seed from a template).
2. Upload a new version.
3. Request/record approval.
4. View protected preview or download (if allowed).

Common tasks (how-to)

• Seed register from template.
• Upload a version and request approval.
• Filter for missing/overdue/needs approval.
• Retry a preview generation.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Create entry | Owners/co-owners/internal contributors | Add items to the register. | | Upload version | Internal contributors | Add new controlled files. | | Approve version | Designated approvers | Mark a version as approved. | | View | Users with project access | External only if explicitly shared. |

Evidence and traceability (high-level)

Version history, approvals, and preview status are logged; files served via protected endpoints.

Good operating routine (weekly/monthly)

• Weekly: check “due soon” / “overdue” review statuses.
• Before release: ensure latest approved versions are attached.
• After uploads: verify preview status.

FAQ (safe)

• **Preview missing?** It may be converting or unsupported; try regenerate.
• **Delete versions?** Prefer superseding with a new approved version.

For administrators: see Internal KB → Document Register (requires login).

Inspections

What this is

Checklists with evidence for project inspections or audits.

When to use it

Use for site checks, audits, or verifications that need structured tasks and evidence.

Key concepts (simple)

• Templates with tasks/criteria.
• Evidence attachments stored via the Document Register.
• Internal discussion & knowledge pack (internal-only).
• Exportable inspection reports.

Step-by-step workflow

1. Create an inspection from a template.
2. Complete tasks and attach evidence.
3. Record findings/actions if needed.
4. (Internal) capture discussion/knowledge pack.
5. Export report if required.

Common tasks (how-to)

• Filter inspections by status/project.
• Upload photos/PDFs as evidence.
• Mark tasks complete and add comments.
• Export a PDF report.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Create/assign inspections | Project owners/co-owners/internal inspectors | Launch inspections. | | Complete tasks | Assigned internal users | Finish checklist and add evidence. | | View inspection | Internal members; externals only if explicitly shared | Internal discussion stays internal. |

Evidence and traceability (high-level)

Evidence stored in the Document Register; discussions/knowledge packs are internal-only and audit-logged.

Good operating routine (weekly/monthly)

• Before start: confirm template and assignees.
• During: attach evidence promptly.
• After: create actions if needed and export report.

FAQ (safe)

• **Can clients see discussions?** No, discussions and knowledge packs are internal.
• **Where are attachments stored?** In the Document Register.

For administrators: see Internal KB → Inspections (requires login).

Deviations & CAPA

What this is

Log nonconformities or near-misses and track corrective/preventive actions to verification.

When to use it

Whenever an issue is found that needs investigation, actions, and proof of effectiveness.

Key concepts (simple)

• Deviation record with category/severity.
• Actions with owners, due dates, and verification step.
• Evidence attachments stored in the Document Register.

Step-by-step workflow

1. Create a deviation.
2. Add actions with owners/due dates.
3. Attach evidence and update status as actions complete.
4. Verify effectiveness before closing.

Common tasks (how-to)

• Create deviations and assign actions.
• Upload evidence.
• Filter by status/severity/project.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Raise a deviation | Internal users | Start the record. | | Assign/complete actions | Internal users with project access | Work the plan. | | Verify/close | Approver roles | Independent verification recommended. |

Evidence and traceability (high-level)

Actions and status changes are logged; evidence lives in the Document Register.

Good operating routine (weekly/monthly)

• Log deviations promptly.
• Keep actions small and time-bound.
• Verify with evidence before closure.

FAQ (safe)

• **Reopen?** Follow your governance; often a new record or action is preferred.
• **External visibility?** Internal by default; external sharing is limited.

For administrators: see Internal KB → Deviations (requires login).

Quality Management (QMS)

What this is

Quality workflows with actions, reviews, and release packages.

When to use it

For managing corrective actions, document workflows, management reviews, and preparing audit-ready releases.

Key concepts (simple)

• Actions with statuses and verification.
• Workflows for documents/CAPA/audits.
• Policy checks that warn/block missing evidence.
• Management Reviews with inputs, minutes, and follow-up actions.
• Release Packages with internal approval before publish.

Step-by-step workflow

1. Create/receive actions from deviations, audits, or reviews.
2. Work actions to completion; request verification.
3. Move items through workflows as evidence/approvals are ready.
4. Run management reviews; store minutes as a document; create actions.
5. Build a release package; get approval; publish after checks pass.

Common tasks (how-to)

• Update “My actions” and add evidence.
• Collect inputs and upload minutes for a management review.
• Build/submit a release package for approval.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Create/assign actions | Internal project/company roles | Manage quality tasks. | | Verify/close actions | Approver roles | Separate from completion. | | Run management reviews | Admin/owner-level roles | Formal review cycle. | | Approve/publish packages | Admin/owner-level roles | Internal approval required first. |

Evidence and traceability (high-level)

Actions, workflow steps, and releases are audit-logged; documents/minutes stored in the Document Register.

Good operating routine (weekly/monthly)

• Daily/weekly: check actions due and verification queue.
• Each review: ensure minutes + actions are recorded.
• Before publish: resolve policy warnings/blocks.

FAQ (safe)

• **Policy block?** Attach required evidence/approvals, then retry.
• **External visibility?** Release packages exclude internal-only notes.

For administrators: see Internal KB → QMS (requires login).

HMS (Project)

What this is

Project-level health, safety, and environment control: required components, risks, training, preparedness, and reviews.

When to use it

Use for any project that needs HSE structure and evidence.

Key concepts (simple)

• HMS profile per project with status/next review.
• Required components with evidence.
• Risk register (physical + psychosocial) with linked actions.
• Action plan using QMS actions.
• Coordination for multi-company sites.
• Training records and preparedness.
• HMS reviews with minutes and actions.

Step-by-step workflow

1. Open HMS from project dashboard; run Setup.
2. Attach evidence to required components; set status.
3. Record risks and create mitigation actions.
4. Maintain training/preparedness records.
5. Run reviews and create follow-up actions.

Common tasks (how-to)

• Update components in Setup.
• Add risks and link actions.
• Check action plan status.
• Add review minutes as a document and create actions.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Setup HMS | Project owner/co-owner/internal HMS roles | Manage components/evidence. | | Add risks/actions | Internal project users | Mitigate and track. | | View HMS | Internal project members | External users are not given HMS access. |

Evidence and traceability (high-level)

Evidence stored in the Document Register; actions follow QMS verification; status changes are logged.

Good operating routine (weekly/monthly)

• Kickoff: complete HMS setup.
• Weekly: review risks/actions.
• Quarterly: run an HMS review and update next review date.

FAQ (safe)

• **Status blocked?** Required components need approved evidence and next review date.
• **External access?** HMS is internal-only.

For administrators: see Internal KB → HMS (Project) (requires login).

HMS Internal (Company)

What this is

Company/domain-level internkontroll: policies, organization, enterprise risks, training, preparedness, and reviews. Projects can inherit the baseline.

When to use it

Use to manage organization-wide HMS and provide a baseline for projects.

Key concepts (simple)

• Internal HMS profile with required components and evidence.
• Enterprise risk register with actions.
• Training requirements and records with expiry tracking.
• Preparedness plan and drill/review notes.
• Internal HMS reviews with actions.
• Baseline templates inherit into projects.

Step-by-step workflow

1. Complete internal HMS setup and attach evidence.
2. Maintain enterprise risks and actions.
3. Define training requirements and record completions.
4. Keep preparedness plan current; log drills/reviews.
5. Run periodic reviews and create actions.
6. Apply baseline when starting projects.

Common tasks (how-to)

• Update components/evidence.
• Add risks and link actions.
• Record training completions and expiries.
• Run reviews and add follow-up actions.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Manage internal HMS | Internal admins/owners | Full control. | | View internal HMS | Internal users | External users cannot access. | | Apply baseline to project | Admin/owner roles | Done during project setup. |

Evidence and traceability (high-level)

Evidence stored in Document Register; actions follow QMS verification; policy checks block activation until core components/evidence/next review are set.

Good operating routine (weekly/monthly)

• Monthly: review enterprise risks and actions.
• Quarterly/annual: run internal HMS reviews and refresh next review date.
• Before project starts: update baseline templates.

FAQ (safe)

• **Activation blocked?** Required components/evidence or next review missing.
• **External visibility?** Internal HMS is never shared externally.

For administrators: see Internal KB → HMS Internal (requires login).

Compliance

What this is

Register obligations, link controls and evidence, and track changes that may require action.

When to use it

Use when you need to track legal/contractual/internal obligations and keep evidence current.

Key concepts (simple)

• Obligations with status and review cadence.
• Controls mapped to obligations.
• Change events that can create actions.
• Evidence links stored in the Document Register.

Step-by-step workflow

1. Add obligations and link controls/evidence.
2. Set review dates and owners.
3. Record change events and create actions if needed.
4. Monitor dashboards for overdue reviews and actions.

Common tasks (how-to)

• Add/update obligations and evidence.
• Link controls.
• Track actions from change events.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | View compliance | Internal users | Read obligation status. | | Manage obligations/controls | Internal compliance/admin roles | Keep evidence current. |

Evidence and traceability (high-level)

Evidence is stored in the Document Register; actions and status changes are logged.

Good operating routine (weekly/monthly)

• Monthly: check upcoming reviews and open actions.
• After regulatory updates: log change, assess, create actions.

FAQ (safe)

• **External involvement?** Compliance content is internal; external users are not involved.

For administrators: see Internal KB → Compliance (requires login).

Roles & Access

What this is

Role-based access with an internal request/approval flow.

When to use it

Whenever users need new access or roles for projects/modules.

Key concepts (simple)

• Roles: Admin, SuperUser, Owner, Co-owner, Internal user, External user.
• Access requests: internal users request roles; approvers decide.
• Approvals are logged.

Step-by-step workflow

1. Submit an access request with justification.
2. Approver reviews and approves/denies.
3. Approved access is applied; changes are logged.

Common tasks (how-to)

• Request access to a role.
• Approve/deny a pending request (for approvers).
• Review current roles.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Request access | Any internal user | Provide justification. | | Approve/deny | Approvers/Admins | Decision recorded. | | Manage roles | Admin/SuperUser | Maintain mappings. |

Evidence and traceability (high-level)

Requests and decisions are logged with timestamps.

Good operating routine (weekly/monthly)

• Review open requests weekly.
• Keep role assignments minimal and justified.

FAQ (safe)

• **Can external users request?** No—external users are invited explicitly.

For administrators: see Internal KB → Roles & Access (requires login).

Diagrams & Builder

What this is

Create and store diagrams (e.g., draw.io) as controlled documents.

When to use it

Use for process maps, technical sketches, or visuals that need versioning and linkage to actions/evidence.

Key concepts (simple)

• Diagram files are documents with versions.
• Previews where supported.
• Can be linked to QMS/HMS evidence or release packages.

Step-by-step workflow

1. Create a diagram document in the project.
2. Edit/save to create new versions.
3. Link the diagram as evidence where relevant.

Common tasks (how-to)

• Create a new diagram entry.
• Upload/save a new version.
• Reference the diagram in actions or components.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | Create/edit diagrams | Internal users with project document access | Manage diagram versions. | | View diagrams | Users with document access | External only if explicitly shared. |

Evidence and traceability (high-level)

Diagrams follow document version/approval rules; stored in the Document Register with protected previews.

Good operating routine (weekly/monthly)

• Keep titles/version notes clear.
• Link important diagrams to relevant actions/components.

FAQ (safe)

• **Where are diagrams stored?** In the Document Register with other documents.

For administrators: see Internal KB → Diagrams (requires login).

Project Cost (if enabled)

What this is

Optional cost view showing high-level project totals.

When to use it

Use when the cost submenu is enabled and you need a quick financial overview.

Key concepts (simple)

• Cost tab/menu inside a project.
• High-level totals as configured by your organization.

Step-by-step workflow

1. Open the project cost tab/menu.
2. Review the latest summary.

Common tasks (how-to)

• View current totals.
• Export/download if enabled by your organization.

Roles (generic)

| Action | Who can do it | What it means | |---|---|---| | View costs | Owners/co-owners/finance roles | External users typically cannot see costs. |

Evidence and traceability (high-level)

Depends on your organization’s data source; not a primary evidence store.

Good operating routine (weekly/monthly)

• Align on how often cost data is refreshed.
• Limit cost viewers to those who need it.

FAQ (safe)

• **Why can’t I see costs?** The feature may be disabled or you may lack access.

For administrators: see Internal KB → Project Cost (requires login).

What’s new (public-safe)

• HMS: project-level HMS setup with required components, risk register, action plan, coordination, training, preparedness, and reviews.
• HMS Internal: company-level internkontroll with enterprise risks, training, preparedness, reviews, and project baseline inheritance.
• QMS: management reviews (inputs, minutes, actions) and release packages with approval and policy feedback; action verification emphasized.
• Document Register: improved templates and control view for due/overdue and missing evidence.
• Inspections: internal discussion/knowledge packs remain internal-only; evidence previews and exports.
• Deviations/CAPA: action verification and evidence-first closure pattern.
• Roles & access: internal users can request access; approvers decide with comments.
• Navigation: HMS and Internal HMS links available from the menu (for users with access).

*For detailed internal changes, see Internal KB release notes (requires login).*