Skip to main content

Using Project Types

Project Types are the fastest way to spin up a new project. Instead of assembling an approval list, fields, and document sets from scratch every time, you pick a project type and the new project is pre-populated from it in one click.

This page summarises the day-to-day workflow. For the full conceptual model, start with Project Types; for step-by-step setup of a new project type, see Configuring a Project Type.

Picking a project type in the wizard​

When you start a new project:

  1. Go to New Project.
  2. On step 1, choose Choose a Project Type as the creation method.
  3. Pick the project type from the list.

ApprovIQ snapshots its approval items, tasks, project information fields, document sets, and any linked approval-pack template into the project. You then move through the rest of the wizard to confirm the list, add team members, and pay. See Creating a Project for the wizard in detail.

Project types are snapshots​

The single most important thing to understand about project types is that the copy in each project is independent from the moment the type is applied.

  • Edits you make inside the project only affect that project.
  • Edits you make to the library or to the project type only affect projects created from that point on.

This trade-off is deliberate: in-flight projects are never retroactively changed, so you can keep refining your library without worrying about breaking live work.

There's one exception: document checks on library approval items propagate to linked projects. See Approval Items and Tasks.

Combining pieces​

A project type is a small container, but each of its constituent pieces (approval items, tasks, fields, document sets, approval-pack template) can belong to any number of project types. Instead of maintaining a separate library entry for every variant, build a small reusable library and combine entries into as many project types as you need.

Typical patterns:

  • A general project type plus specialised project types that add a handful of extra items or tasks.
  • One project type per discipline (e.g. Residential CC, Commercial CC, Fire Safety CC) that share a common pool of approval items but differ in their project information fields or document sets.
  • A "minimal" project type used as a starting point when none of your configured types quite fit.

When to edit vs when to create a new project type​

  • Edit an existing project type when you want the change to apply to every future project of that type.
  • Create a new project type when a new kind of project has genuinely different requirements — different items, different document sets, or different information fields.

If two project types would be nearly identical, prefer one project type and adjust the specific project after creation.

Best practices​

  1. Start broad, then specialise — ship a general project type first, then clone it and refine for specific variants.
  2. Invest in document checks — checks on library approval items propagate to every active project, so time spent refining them compounds.
  3. Use project-type-specific descriptions — keep the base description reusable and let the project type supply the context that only applies to that type.
  4. Review after each project — after completing a project, ask whether any adjustments you made on the project should be promoted back into the library or the project type.