FolksPMS

FolksPMS is an enterprise Project Management Suite that runs a project from first estimate to final reconciliation on a single SQL-Server-backed engine. It is built on .NET 9 Blazor Server + ASP.NET Core Web API + SQL Server, and organised into 34 modules grouped under 8 navigation pillars.

1.1 The eight pillars

1.2 The data flow at a glance

Every user has a Login, an Employee profile and one or more Roles. Roles are not labels — they drive exactly which menus, pages and actions you can reach.

Live screenshot   The FolksPMS sign-in page.

2.1 Signing in

1. Open the FolksPMS front-end URL. Enter Username and Password.
2. On success the API issues a JWT; the front-end resolves your role and redirects you to its default landing page — usually the Command Center.
3. If your login status is Inactive or Blocked, sign-in is refused and only an administrator can restore it.

2.2 Roles you'll meet

2.3 The RBAC chain

FolksPMS pages come in a handful of consistent shapes. Learn the pattern once and every one of the 369 pages feels familiar.

3.1 The four page archetypes

3.2 Anatomy of a list page

3.3 Conventions that hold everywhere

• Codes auto-generate. Leave the code field blank when adding — the SP fills a human-readable identifier (e.g. PRJ-2026-0007).
• Soft delete. Most rows carry IsActive — prefer deactivation over physical delete so history survives.
• Stamping. CreatedBy / CreatedDate / UpdatedBy / UpdatedDate are filled from your token — the Audit trail depends on it.
• Every dropdown is a picklist. Status, Priority and Severity all read from the central SP_Picklists table — see System Parameters.
• Files go through Documents. Binaries never sit in an entity table — they're uploaded via the hook and referenced from Documents.

This is the single idea that organises FolksPMS. The same project task is expressed at six levels of fidelity, each refining the last. Because all six share one underlying shape, the multi-level Gantt can overlay any level on any other — and the gap between the frozen plan and reality becomes a measurable, governable signal.

4.1 How a level feeds the next

4.2 Overlaying levels

The multi-level Gantt lets you toggle any level on or off and compare them in one chart. The most important comparison is Kick-Off vs Actuals — the baseline bar and the actual bar drawn together, so slippage is visible at a glance.

Green = frozen Kick-Off baseline · Amber = Actuals · Red diamond = milestone. The amber bars running past the green ones are exactly what the Deviation Engine measures.

4.3 The deviation loop

The left navigation groups all 34 modules into eight pillars. Each module routes as /w/{Mc}/{Sub} and is documented in this manual as #mod-XX by its two-letter code. Click any chip to jump.

Command Center & operational dashboards.

The Command Center is the post-login landing page and the executive heartbeat of FolksPMS. It rolls up live counts from every pillar — active projects, open tasks, pending approvals, deviation alerts and budget burn — into a single glanceable cockpit.

Dashboards here are read-mostly: they aggregate other modules through DevSP_* rollup procedures rather than owning transactional data of their own.

Live screenshot   The Command Center — live KPI rollups across the eight pillars.

How it works

Concepts that matter

The project register — the spine of the suite.

Projects is the master entity that almost every other module references. A project carries its code, client, currency, planned dates, budget envelope and live status, and fans out to child records: phases, the delivery team, and the project charter.

Because the project ID threads through tasks, budgets, schedules, change requests and tickets, getting the project record right is the single most important data-entry act in FolksPMS.

Live screenshot   The project register, with health buckets derived from status + progress.

The project lifecycle

Concepts that matter

Roles

Tables you'll touch

Programmes — portfolios of related projects.

A Programme groups several projects that share an outcome, sponsor or funding line. Programmes let executives steer a portfolio: aggregate budget, combined milestones and shared benefits roll up here.

Projects link up to a programme; the programme never owns the project's transactional detail, only the relationship and portfolio-level fields.

How it works

Concepts that matter

Planning board — shaping work before it is scheduled.

Planning is where work is shaped: planning items, backlog entries and capacity assumptions are captured before they harden into a scheduled Gantt. Think of it as the bridge between "we should do this" and "this is on the plan".

Planning records are deliberately lightweight — they carry intent and rough sizing, and graduate into tasks or schedule lines once committed.

How it works

Concepts that matter

Level 1 — the first cut of the plan.

The Estimation Gantt is the first cut: rough-order-of-magnitude tasks and durations used to size the work and win the mandate. Estimates here feed the budget.

All six levels share the same task shape so they can be overlaid on one chart — the multi-level Gantt toggles let you compare any level against another (e.g. Kick-Off vs Actuals).

How it works

Level 2 — the estimate, costed into money.

The Budgeting Gantt converts the estimate into money: a budget header with cost lines mapped to tasks and phases. This is the financial baseline the Actuals later reconcile against.

How it works

Level 3 — work on a real calendar.

The Scheduling Gantt turns sized, budgeted work into a real calendar: tasks with start/end dates, dependencies and the critical path. This is the working schedule the team executes against.

How it works

Level 4 — the frozen baseline.

At project kick-off the schedule is frozen into a baseline. The Kick-Off Gantt is immutable: it is the agreed plan against which every later actual and deviation is judged. Re-baselining is a governed event, not an edit.

Live screenshot   The Kick-Off Gantt — the frozen baseline every actual is measured against.

How it works

Level 5 — what really happened.

The Actuals Gantt records what really happened: actual start/finish, actual progress and actual cost as work is delivered. Overlaying it on the Kick-Off baseline reveals slippage at a glance.

How it works

Level 6 — where execution meets governance.

The Deviation Engine is the signature of FolksPMS. It continuously compares Actuals (AG) against the frozen Kick-Off baseline (KG) and, when variance breaches a threshold, auto-promotes the deviation into a Change Request — closing the loop between execution and governance with no manual hand-off.

The detection-to-governance loop

Concepts that matter

Severity thresholds (example)

Tasks — the unit of delivery.

Tasks are the atomic units of work. Each task belongs to a project (and usually a phase), carries a status and priority, and accumulates comments, attachments and dependencies as it is worked.

Where the Gantts plan time, Tasks track the day-to-day reality of who is doing what, and surface blockers early through status and dependencies.

Live screenshot   The Tasks board — owner, status, priority and due labels at a glance.

The task lifecycle

Concepts that matter

Tables you'll touch

Resources — people, roles and allocation.

Resources manages the people (and sometimes equipment) available to projects: their roles, rates and how their capacity is allocated across the schedule.

Resource allocation is what makes the schedule honest — a Gantt that ignores who is available is fiction.

How it works

Time & Attendance — timesheets and presence.

Time & Attendance captures effort against tasks (timesheets) and presence (attendance). Logged time feeds actual labour cost and progress; attendance underpins capacity and compliance.

Approved timesheets are the source of truth for actual effort that the Actuals Gantt and budget reconciliation rely on.

How it works

Materials — items, requisitions and goods receipt.

Materials tracks the physical items a project consumes: the catalogue, stock, requisitions raised against projects, and goods-received notes (GRN) when supply arrives.

Materials shares the Requisition and GRN concepts with the Buy/Sell module — here the focus is internal consumption, there it is external purchasing.

How it works

Quality — checklists, inspections and defects.

Quality Assurance records inspections, quality checklists and defects. Defects carry a severity and a status lifecycle from raised to closed, giving a measurable picture of delivery quality.

Quality data feeds governance: a spike in high-severity defects is exactly the kind of signal Escalations and the Command Center should surface.

How it works

Goals · OKR — objectives and key results.

Goals / OKR aligns delivery to outcomes. Objectives carry measurable key results; progress on key results shows whether the work is moving the needle, not just keeping busy.

OKRs connect the strategic "why" (often a programme benefit) to the tactical "what" (tasks and milestones).

How it works

Change Requests — the controlled path to change.

Change Requests is the governed funnel for any change to scope, schedule or budget. CRs may be raised by hand or created automatically by the Deviation Engine when a baseline breach is detected.

A CR moves through a status lifecycle (Draft → Submitted → Approved/Rejected → Implemented) with an approval gate, so every material change has an owner, a rationale and a decision on record.

Live screenshot   Change Requests — including the ones the Deviation Engine raised automatically.

The CR lifecycle

Approvals — workflows, steps and delegations.

Approvals provides the reusable approval machinery the rest of the suite plugs into: a workflow definition, its ordered steps, delegations for when an approver is away, and the approval records themselves.

When a CR, timesheet, requisition or leave needs sign-off, it routes through an Approvals workflow and lands in the approver's queue.

How it works

Tables you'll touch

Escalations — surfacing what is stuck.

Escalations raises the alarm when something breaches an SLA or sits unresolved: a blocked task, an overdue approval, a high-severity defect. Escalations carry their own status lifecycle and route to the right level.

Escalations are the immune system of the suite — they make sure problems get attention before they become incidents.

How it works

Compliance — obligations and evidence.

Compliance tracks the regulatory, contractual and policy obligations a project must satisfy, and the evidence that proves it. Each obligation has a status and an owner.

Compliance turns "we should be compliant" into an auditable register of who owns what and whether it is met.

How it works

Audit — the immutable record of who did what.

Audit reports expose the trail: who changed which record, when, and from what to what. Audit is read-only by design — it observes the rest of the suite rather than owning data.

Combined with the platform's CreatedBy / UpdatedBy stamping, Audit answers the question every governance review asks: prove it.

How it works

Documents — the versioned project library.

Documents is the project's filing cabinet: documents, versions and folders. Binary files are stored via the upload hook; the table holds metadata, version and the link.

Charters, evidence, drawings and contracts all live here so other modules can reference a single source of truth.

How it works

Calendar Sync — events and external calendars.

Calendar Sync publishes project milestones, meetings and deadlines as calendar events and keeps them in step with external calendars.

It is the lightweight glue that puts project dates where the team already looks — their own calendar.

How it works

Notifications — the message queue.

Notifications is the suite's outbound message queue: templates define the message, the queue holds pending sends, and a status tracks delivery.

Approvals, escalations and deviations all drop notifications here rather than mailing directly, so delivery is observable and retryable.

How it works

Training — courses, sessions and records.

Training manages the courses people need, the sessions that deliver them, and the records of who completed what. It underpins competency and compliance.

Training records prove a resource is qualified for the role they are allocated to — a quiet but important governance link.

How it works

Tickets · Helpdesk — issues and support requests.

Tickets / Helpdesk is the intake desk for issues and support requests that aren't planned tasks: a stakeholder query, a defect report from the field, an access request. Tickets carry priority and a status lifecycle.

Tickets that turn out to be real work can be promoted into tasks or change requests, keeping the planned plan clean.

How it works

Buy / Sell — procurement and purchasing.

Buy / Sell handles external procurement: purchase requisitions, purchase orders to vendors, and goods receipt (GRN) when they deliver. It is the money-out counterpart to delivery.

BF shares the Requisition and GRN vocabulary with Materials; here the counterpart is an external vendor and a PO, not internal stock.

How it works

Sub-Contractors — external delivery partners.

Sub-Contractors manages the partners who deliver parts of the work: their contracts, scope packages, and performance. It brings external delivery under the same governance as internal work.

Sub-contractor packages link to the schedule and budget so external work is planned and costed alongside your own.

How it works

Reports — cross-module reporting.

Reports is the standard reporting surface: parameterised, filterable reports that draw across modules through DevSP_* procedures. Where module Report pages give a module view, RM gives the cross-cutting view.

Reports are read-only and built for export — the format finance and the steering committee expect.

How it works

Insights — analytics and trends.

Insights turns the warehouse of project data into trends and predictions: burn rates, deviation patterns, resource utilisation, quality trajectories. It is the analytical layer above plain Reports.

Insights answers "what is likely to happen" where Reports answers "what happened".

How it works

Client Master — the customer register.

Client Master holds the customers projects are delivered for: client records, contacts and contracts. Every project references a client, so this register is a prerequisite for project creation.

Clean client data here flows into every invoice, report and contract reference downstream.

Live screenshot   The Client Master — every project's Client dropdown reads from here.

How it works

Tables you'll touch

Organisation — internal structure.

Organisation models your own company: business units, departments, locations and the org hierarchy. It is the internal mirror of Client Master.

Org structure scopes reporting and resource pools — knowing which unit owns a project drives a lot of rollups.

How it works

System Parameters — the configuration backbone.

System Parameters holds the suite's configuration: global settings, the central SP_Picklists lookup that powers every Status/Priority/Severity dropdown, currencies and number sequences.

Almost every dropdown you see elsewhere is fed from here. Changing a picklist value here changes it everywhere — with the matching CHECK constraint kept in step.

How it works

Tables you'll touch

User Management — identity, RBAC and workflow.

User Management is the shared, locked platform foundation: users and logins, employees, departments, designations, roles and the menu/privilege matrix that drives what each role can see and do — plus the workflow listener.

UM is inherited verbatim from the Folks platform and shared across products. It is documented here as reference; changes to UM affect every consuming application, so treat it as read-only in a PMS context.

How it works

Roles

Every coded dropdown in FolksPMS is fed from SP_Picklists (see System Parameters). These are the values you'll meet most, and the colour each maps to on a list page.

Project & task status

Priority & severity

Change Request lifecycle

FolksPMS is deliberately SQL-first: business logic lives in stored procedures, not in an ORM. Understanding the naming convention lets you predict where any piece of data lives.

Naming conventions

The request path

FolksPMS ships fully bilingual — English and Saudi Arabic (ar-SA) — with a complete right-to-left layout. The toggle sits in the top navigation; switching language flips the entire UI mirror-image, not just the text.