Project Templates

If you run the same shape of project over and over — the same phases in the same order, the same checklist at each stage — a template lets you describe that shape once and create it in a few clicks instead of rebuilding it by hand every time.

A template holds the structure and the timing, and nothing else. The client, the team and every financial detail belong to the project you create from it, not to the template.

Who can use templates

Projects Viewer and Projects Manager can open the templates list and create projects from a template.
Only a Projects Manager can build or change a template itself.

So if your role is Projects Viewer you can see which templates exist and start projects from them, but opening one takes you to the template editor, which a Projects Manager holds. The permission comes from your role, which an Administrator assigns.

Project templates are available wherever projects are: an organisation that does not use the projects side of Flowtly does not see them.

The templates list

Project templates sits beside Projects in the sidebar, because a template belongs to the organisation rather than to any one project.

The list gives each template a name, its structure and its project type. The structure column is the quickest way to tell two templates apart — it reads "2 phases · 4 lists", so a half-built copy does not look like the real thing. A template with no phases says "No phases · 3 lists", since a plain checklist is a perfectly good template and a zero would read like something was missing.

Search filters the list by template name.

What a template describes

A template is a small tree:

The project — its name and its type (Fixed price, Time and material, Non billable or Internal).
Phases — the stages the work runs through, in order. Each phase becomes a child project in Flowtly, which is how phases already work on projects you build by hand.
Task lists — named groups of tasks, on the project or on any phase. Tasks that are not put in a named list land in the project's default list.
Tasks — the individual pieces of work.

How the dates work

Nothing in a template stores a calendar date. Everything is stored as a number of days relative to the start date you pick when you create the project.

Two numbers describe each phase and each task:

Start offset — how many days after the project starts it begins. An offset of 0 means it starts on day one, together with the project.
Duration — how many days it lasts. Durations are inclusive: something that starts on day 1 with a duration of 5 runs day 1 through day 5, and finishes at the end of day 5.

So a template describes "kickoff lasts a week, build starts three weeks in and runs for two months", and choosing a start date of 1 September turns that into real dates. The same template used in March produces March dates.

Building a template

New template on the templates list opens the editor. It has the template's own name at the top, the outline on the left and the properties of whatever you have selected on the right.

The outline is the tree itself: the project at the top, then its phases, their task lists and the tasks inside them. Select a row and the panel on the right edits that row — the project's name and type, a phase's name, order, start offset and duration, a task's title and dates. As you set a start offset and a duration, the panel tells you which day the item ends on.

Adding follows your selection, so that a new item lands where you are looking:

Phase adds a phase to the project.
List in this phase adds a task list to the phase you have selected. With the project selected it adds the list to the project itself.
Task in this list adds a task to the selected list.

Phases can be moved up and down, and any row can be removed. Nothing is stored until you choose Save. If something in the structure is not allowed — a duration below one day, for instance — the message appears on the field that caused it rather than as one warning about the template as a whole.

Creating a project from a template

Templates are not a separate way to start a project. Creating a new project opens a dialog with two tabs — Blank and From a template — because they are the same intent with different starting material.

On the From a template tab you give Flowtly three things:

Which template to use.
The start date — every offset in the template is counted from this day.
A name for the new project. Leave it empty to use the template's own name.

Beside the form, a preview shows the tree you are about to create, with real dates on every phase and task, and a line summarising it: how many projects, lists and tasks it comes to. Change the start date and the preview re-dates itself, so you can check the shape against the calendar before committing to it. This is worth reading, because there is no confirmation step afterwards and no single undo.

Choosing to create then writes the project, all of its phases, their task lists and their tasks in one step, and takes you to the new project. If anything goes wrong part-way, nothing is created at all — you never end up with half a project to clean up.

Remember that a phase is a child project, so a template with three phases creates four projects: the one you named and its three children. The preview's summary counts them that way.

What a template does not carry over

Deliberately, a template never contains:

A client. Set one on the new project afterwards, as you would on any project.
Team members or rates. Add people to the new project as usual.
Budgets, invoices or logged time. Nothing financial is copied, so using a template can never move money or change a report.

This is what makes a template safe to reuse across clients: it is a shape, not a copy of a previous engagement.

Editing a template

Editing a template changes only what happens next. Projects you already created from it are ordinary projects and are never touched — they do not re-shape themselves when the template changes.

That also means fixing a mistake in a template does not fix it in the projects already made from it. Those you correct individually.

Example use cases

A repeatable client engagement. An onboarding that always runs discovery, setup, migration and handover — described once, started on whatever date each new client signs.
An internal process with a fixed rhythm. A quarterly audit or a release cycle whose stages always sit the same distance apart.
A standard checklist. A short template with no phases at all, just a task list, so that nothing gets forgotten at the start of a project.