GO has two ways to stop rebuilding the same job from scratch. A Project Template is a complete project — task tree, resources, budgets, checklists — frozen for reuse: pick it, name the new job, and a whole project appears. A Task Package is smaller: a named bundle of tasks you drop into an existing project. Templates start jobs; packages add to them.
| Project Template | Task Package | |
|---|---|---|
| Produces | A brand-new project | Tasks added to an existing project |
| Managed in | Projects page → Templates tab | Task Planner → right-click → Packages |
| Built from | An existing project ("Save as Template") | A multi-selection of tasks in the planner |
Project Templates
Creating a template
The usual path: build (or find) a project that represents the job type, then save it as a template. Two ways:
From the project dialog — tick the Save as Template checkbox. The form swaps: a required Template Name and a Template Description appear, and the Account field disappears — templates belong to no customer.
Duplicate an existing template — on the Templates tab, right-click → Duplicate Template.
Saving as a template copies the project's type, profit center, tax entity, branch, team roles, financial amounts, notes, tags — and the entire task tree with each task's resources, assemblies, checklists, and tags. What it deliberately clears: the account, the location, all dates, and all actuals. Budgets stay; history of work performed doesn't.
Creating a project from a template
Go to Projects → Templates tab, right-click the template → Create Project from This.
Step 1: confirm the template — the summary shows its description and task count. Click Next.
Step 2: fill in what a template can't know: the Account (required), Start Date (required), Project Name (pre-filled, required), and optionally a Location. Click Create Project.
The new project gets the full task tree with resources, checklists, and tags. The new account is written onto every task and resource line. Two things to plan for immediately after:
No task has any dates. The project's start date does not cascade down — scheduling the tasks is your next step, in Schedule or the Gantt.
Every task starts at the beginning of the default task workflow, regardless of where the template's tasks stood.
Task Packages
What a package is
A package is a named pointer to a set of real tasks — typically on a "library" project you maintain for the purpose. Because it points rather than copies, editing those source tasks changes what every future apply produces. That's a feature (one place to maintain the standard) and a thing to know (don't build packages from tasks on live client jobs that will drift).
Creating a package
In the Task Planner, multi-select the tasks to bundle.
Right-click → Packages to open the Task Packages dialog, then click Create from {n} Selected.
Name it (e.g. "Residential Full Landscape"), optionally set a Category and Description, and click Create.
In the dialog you can expand any package to see its tasks, double-click its name/category/description to edit, right-click to Clone or Delete a package, or right-click a task inside one to remove it. Deleting a package never touches the underlying tasks.
Applying a package
Two places:
Task Packages dialog — with a project in context, right-click a package → Add {package} to {project}.
Project dialog → Tasks tab — a project with no tasks shows Initialize from Package; one with tasks shows Add More from Package. This picker lets you tick several packages at once, grouped by category, and de-duplicates tasks that appear in more than one.
Applying creates brand-new tasks on the target project — the source tasks are never moved. Each new task carries the name, description, budgets, resources (with pricing), checklists, and tags of its source, re-pointed at the target project's account. It also carries the settings that decide what the work costs and what it bills at: pay classification, workers' comp class, jurisdiction, rate schedule override, unit of measure, hourly bill rate, bill type, and minimum hours. (These used to come across blank, which quietly costed the labor wrong on the new task — they now follow the source.)
What doesn't come across, same as template replication: no dates and no team assignment — schedule and assign after applying.
Each new task starts at the first state of its source task's workflow. If the source task doesn't carry a workflow of its own, the new task falls back to the business unit's default Task workflow.
One prerequisite, and only in that fallback case: if a package's source tasks carry no workflow, the business unit needs a default Task workflow with an initial state, or the apply refuses with exactly that message. Packages built from tasks that already have their own workflow apply without it.
Good to know
Template financials copy onto the new project. Contract amounts, budget, and even invoiced/received totals come from the template — so build templates from clean, representative projects, not from a mid-flight job whose numbers will masquerade as the new job's history. (Actual labor and cost figures do reset to zero.)
Resource pricing copies as-is. Rates on a template or package are not re-priced for the new customer — review pricing after creating from an old template, especially across price increases.
Recurring tasks come back as one-offs. Recurrence settings don't survive templates or packages; re-establish them on the new project.
Template names must be unique across all projects — saving the same project as a template twice under the same name fails validation.
Packages can't be deactivated from the UI — retiring one means deleting it (the tasks it pointed at are unaffected).
Permissions: saving and managing templates needs manage templates; creating projects from templates needs clone template; everything package-related needs manage packages. Applying packages from the project dialog additionally requires edit rights on that project.
Related reading: Projects, Tasks, and Workflows (the workflows applied tasks start in).