DuneSpan Platform
PROJECTS
PROJECTS is the execution layer: tasks, milestones, schedules, owners and dependencies across engineering, production, certification and delivery.
In the app it sits under Project Management, as DuneSpan Projects and Tasks.
In the app it sits under Project Management, as DuneSpan Projects and Tasks.
A deeper look
What PROJECTS is and what it does
PROJECTS is the execution layer of DuneSpan. Where FLOW moves a job between departments, PROJECTS breaks the work inside those stages into tasks, milestones, schedules, owners and dependencies, and tracks them through engineering, production, certification and delivery.
In the app it sits under Project Management in the sidebar, as DuneSpan Projects and Tasks: the place where a stage of work becomes a dated plan with a named owner on every line, a predecessor chain that holds, and a critical path that is visible before a delivery date moves.
In category terms FLOW belongs to the BPM and workflow-management layer, while PROJECTS belongs to the project and PMO-tools layer, the space occupied by tools such as Jira, Microsoft Project and Asana.
On the DuneSpan architecture diagram PROJECTS is amber; the adjacent FLOW layer is coral red.
On the architecture diagram
What PROJECTS covers
PROJECTS turns a stage into a dated, owned plan, and reports it back.
Inside the product
What the screens show today
The sidebar around these screens also carries Dashboard, Projects, WIP Tracking, Quality Control, Enterprise Intelligence, Workflow, Carbon and Price List.
Two layers, one record
How FLOW and PROJECTS work together
FLOW owns the job record and its stage. When a stage needs detailed work, FLOW raises a PROJECTS task pack, and PROJECTS reports progress back so FLOW's status stays true.
The simple version
A customer uploads drawings. FLOW creates the controlled job record and routes it to engineering. PROJECTS then manages the detailed tasks: drawing review, BoM check, procurement input, production release, quality record preparation, and the customer submission deadline.
Worked example
A fire damper order, enquiry to despatch
The module leading each step is named at the end of the line. This routing is a client design rather than a description of every deployment.
Enquiry to order
- Enquiry received by portal upload or email; FLOW creates the controlled job record
- Estimation task pack raised in PROJECTS, with INTELLIUM reading the drawings and flagging ambiguous items to a named engineer
- Approval gate 1, internal technical review in FLOW; non-compliant lines resolved, or accepted with a reason
- Offer issued, each revision versioned and attributable — FLOW
- Order received; the ERP writes the sales order and stays the system of record
- Submittal package generated from the same requirement register — FLOW, with PROJECTS tracking the package tasks
- Approval gate 2, consultant approval in FLOW: approved, approved as noted, or revise and resubmit
- Configuration freeze; production drawings and the cut list come from the approved configuration — FLOW
- Work order released to production; HexaGrid OI takes over station events and QC holds
- Approval gate 3, QC release in FLOW with test evidence attached to the unit serial
- Despatch, with the evidence pack assembled automatically — FLOW
Submittal to despatch
In the field
What clients use PROJECTS for
In the CAD engineering approach, PROJECTS was positioned as the natural third step after INTELLIUM and FLOW rather than part of the starting scope.
Use cases
Where the modules come together
Packages
Where FLOW and PROJECTS sit
Exact module scope per package is confirmed at proposal stage.
Foundations
What PROJECTS runs on
FLOW and PROJECTS both run on Alterion Core, the platform backbone: identity, roles and permissions; the company and site model; the enterprise object model of customer, job, order, drawing, BoM and task; the workflow engine; the data and file layer; and the audit trail.
Integrations
- ERP connected at the sales work order stage, with the ERP remaining system of record for orders and write-backs passing through FLOW approval
- CAD and CAM reached through expert packs, including a structured handoff into EPLAN
- PLM, MES and CoralDune AI tools, where workflow control gains from the integration
Hosting fit
- A custom CoralDune application
- A managed private cloud
- A SaaS-style private deployment
Both modules suit all three.
Want PROJECTS planning the work?Tell us where your delivery dates are slipping.
Contact usDuneSpan Platform
PROJECTS
PROJECTS is the execution layer: tasks, milestones, schedules, owners and dependencies across engineering, production, certification and delivery.
In the app it sits under Project Management, as DuneSpan Projects and Tasks.
In the app it sits under Project Management, as DuneSpan Projects and Tasks.
A deeper look
What PROJECTS is and what it does
PROJECTS is the execution layer of DuneSpan. Where FLOW moves a job between departments, PROJECTS breaks the work inside those stages into tasks, milestones, schedules, owners and dependencies, and tracks them through engineering, production, certification and delivery.
In the app it sits under Project Management in the sidebar, as DuneSpan Projects and Tasks: the place where a stage of work becomes a dated plan with a named owner on every line, a predecessor chain that holds, and a critical path that is visible before a delivery date moves.
In category terms FLOW belongs to the BPM and workflow-management layer, while PROJECTS belongs to the project and PMO-tools layer, the space occupied by tools such as Jira, Microsoft Project and Asana.
On the DuneSpan architecture diagram PROJECTS is amber; the adjacent FLOW layer is coral red.
On the architecture diagram
What PROJECTS covers
PROJECTS turns a stage into a dated, owned plan, and reports it back.
Inside the product
What the screens show today
The sidebar around these screens also carries Dashboard, Projects, WIP Tracking, Quality Control, Enterprise Intelligence, Workflow, Carbon and Price List.
Two layers, one record
How FLOW and PROJECTS work together
FLOW owns the job record and its stage. When a stage needs detailed work, FLOW raises a PROJECTS task pack, and PROJECTS reports progress back so FLOW's status stays true.
The simple version
A customer uploads drawings. FLOW creates the controlled job record and routes it to engineering. PROJECTS then manages the detailed tasks: drawing review, BoM check, procurement input, production release, quality record preparation, and the customer submission deadline.
Worked example
A fire damper order, enquiry to despatch
The module leading each step is named at the end of the line. This routing is a client design rather than a description of every deployment.
Enquiry to order
- Enquiry received by portal upload or email; FLOW creates the controlled job record
- Estimation task pack raised in PROJECTS, with INTELLIUM reading the drawings and flagging ambiguous items to a named engineer
- Approval gate 1, internal technical review in FLOW; non-compliant lines resolved, or accepted with a reason
- Offer issued, each revision versioned and attributable — FLOW
- Order received; the ERP writes the sales order and stays the system of record
- Submittal package generated from the same requirement register — FLOW, with PROJECTS tracking the package tasks
- Approval gate 2, consultant approval in FLOW: approved, approved as noted, or revise and resubmit
- Configuration freeze; production drawings and the cut list come from the approved configuration — FLOW
- Work order released to production; HexaGrid OI takes over station events and QC holds
- Approval gate 3, QC release in FLOW with test evidence attached to the unit serial
- Despatch, with the evidence pack assembled automatically — FLOW
Submittal to despatch
In the field
What clients use PROJECTS for
In the CAD engineering approach, PROJECTS was positioned as the natural third step after INTELLIUM and FLOW rather than part of the starting scope.
Use cases
Where the modules come together
Packages
Where FLOW and PROJECTS sit
Exact module scope per package is confirmed at proposal stage.
Foundations
What PROJECTS runs on
FLOW and PROJECTS both run on Alterion Core, the platform backbone: identity, roles and permissions; the company and site model; the enterprise object model of customer, job, order, drawing, BoM and task; the workflow engine; the data and file layer; and the audit trail.
Integrations
- ERP connected at the sales work order stage, with the ERP remaining system of record for orders and write-backs passing through FLOW approval
- CAD and CAM reached through expert packs, including a structured handoff into EPLAN
- PLM, MES and CoralDune AI tools, where workflow control gains from the integration
Hosting fit
- A custom CoralDune application
- A managed private cloud
- A SaaS-style private deployment
Both modules suit all three.
Want PROJECTS planning the work?Tell us where your delivery dates are slipping.
Contact us