Skip to main content
    Best Practices

    Project Templates in NetSuite

    What Gets Copied, What Doesn't, and How to Keep Them Useful

    Brian Wenzl
    Brian Wenzl
    The Glue Guy

    If you run a creative or professional services agency, charge-based billing is almost certainly the right billing type for your projects in NetSuite. It handles the widest range of billing arrangements, supports rate cards for custom pricing, lets you mix billing methods within a single project, and connects cleanly to Advanced Revenue Management when you need ASC 606 compliance. Pure hourly T&M works fine if your billing is genuinely simple and stays that way. The other billing types have their place, but most agencies ultimately land on charge-based.

    That choice has a direct consequence for how you think about project templates. Charge-based billing is configured through charge rules, and charge rules copy when you create a project from a template. That means your billing logic either travels with your templates or gets recreated manually on every project, by whomever happens to be doing the setup that week.

    This post covers exactly what a template carries forward, what it doesn't, and how to build templates that stay useful as your agency and your client base evolve.

    What a Template Is

    A project template is a saved project structure with no client data, no transactions, and no time history attached. You can build one from scratch via Lists > Relationships > Project Templates > New, or convert an existing project using "Save As Template." When a Project Manager creates a new project from a template, NetSuite runs a background conversion that copies the template's contents into the new project record. After that, the template and the project are fully independent. Updates to the template will not affect existing projects.

    What Copies Over

    The task structure completely copies:

    • Names,
    • estimated hours,
    • dependencies, and
    • hierarchy, if you've built one.

    Generic resource assignments copy, too. These are role-level placeholders rather than named employees. Typically the PM makes the actual staffing decision when the project spins up.

    The most significant thing is the Charge Rules. Although Charge Rules have default values, manually adding Time, Expense, and Purchase Rules to every project quickly becomes tedious.

    A typical agency retainer might need a fixed monthly fee rule firing on the first of each month, a time-based rule capturing overage hours at billing-class rates, and an expense pass-through rule. Build it once in a template and it arrives intact on every new project, correctly staged and ready to generate charges before anyone has logged an hour.

    Pro Tip

    A note on rate cards: if your agency uses a small number of rate cards that apply across most clients, set the rate card in the template. If your clients regularly get custom pricing, leave the field blank. The template rate card overrides the client-level default. That’s convenient when it's correct, and a source of billing errors when it isn't.

    What Doesn't Copy Over

    Individual employee assignments, like Project Manager, can’t be set on a project template. Neither can the client. Those belong on the project record, where they reflect the actual terms of the actual engagement. If you find yourself trying to encode client-specific terms into a template, or make a template where Bob is always the PM, you’re doing too much with your templates.

    Custom Fields and Import Limitations

    Any custom field on your project record form can be made available on the template by checking “Project Template” in the field's Applies To section. If a custom field carries information that should be consistent across all projects of a given type, add it to the template and set it there.

    One custom field worth adding deliberately is a "Template Created From" field. NetSuite does not record which template a live project originated from. Without this field, you lose traceability as templates evolve and project setups drift. To create it, go to Customization > Lists, Records & Fields > Entity Fields > New. Set the type to List/Record > Project Templates, and choose both Project and Project Template under Applies To. Add the field to your project form somewhere visible but out of the way of required setup fields.

    Then open a template record, find the field, and select the template you’re on, creating a self-reference. That value copies to every project created from that template. Any project record then carries a link back to the template that created it, allowing you to report on template use frequency. It can also be handy for troubleshooting Charge Rules.

    NetSuite's import assistant doesn't expose the template field, so there's no way to select a template as part of a CSV import. Worse, template selection isn't something you can add to a project after it's been created. The background copy process that pulls in your task structure and Charge Rules only fires at the moment a project is created through the UI. If you're importing projects, you're getting none of that. You'll need to import your tasks separately and build your charge rules by hand, because charge rules can't be imported either.

    That leaves you with a hard decision if you have many projects to create at once, i.e. after an acquisition. Projects created through the UI get the full benefit of templates. Projects created through import get none of it. The workaround – emphasis on work – is to create “shell” projects in the UI using the appropriate template, then run a CSV update to populate the remaining fields. It works, but it's a grind.

    On Depth and Complexity

    The right number of templates depends on how your agency sells. A firm with three distinct service lines probably wants three templates. One that does bespoke work every time may only need one loose starting point. More than a handful is usually a sign that your templates are trying to do too much.

    The same restraint applies to task count within each template. Somewhere between five and fifteen tasks is the right range. That’s enough to represent the real shape of a project, but not so many that the first thing a PM does is delete things.

    Start flat. Add phases and hierarchy when you genuinely need to roll up reporting at a phase level or manage distinct segments of work separately. The tasks in a template should represent primary phases and deliverable categories. People add tasks as work evolves. The template's job is to get the project most of the way there.

    Before You Publish a Template

    Create one test project from it first. Walk through what a PM would actually need to configure on day one.

    Does the task structure closely resemble a real project? Are the Charge Rules present and set up how you want, including Charge Stage? Is the "Template Created From" field populated? Is what remains for the PM to configure a short, manageable list of items?

    If the test project requires substantial cleanup, the template needs revision. A template that saves real time on project setup is worth maintaining. One that requires its own checklist to use correctly is overhead, not leverage.

    Resources

    Creating Project Templates — Oracle's official documentation on building and using project templates in the native NetSuite module.

    Project Templates Overview — The broader template reference, including role permission requirements.

    Understanding Charge Rules — How charge rules work, which is the context you need to configure them well in a template.

    Creating Charge Rules — Step-by-step configuration reference for all four charge rule types.

    Billing Rate Cards — Rate card setup and billing class configuration, relevant to time-based charge rules in templates.