Fleetwise Docs

Organizing Your Fleet

How to map your company structure onto Fleetwise workspaces, projects, work packages, and usage plans.

Every organisation is different. You may have one brand or several, a single test facility or a network of internal and external sites, a centralized fleet team or distributed departments managing their own vehicles. Fleetwise is designed to accommodate all of these structures.

This page helps you decide how to map your company's brands, locations, teams, and test programmes onto Fleetwise's building blocks so that the right people see the right work.

Building Blocks

Fleetwise organises data in four nesting levels. Each level serves a distinct organisational purpose.

LevelOrganisational RoleExample
WorkspaceCompany, division, or business unit"Acme Automotive R&D"
ProjectVehicle programme, model, or campaign"Model X BEV 2027"
Work PackageTest objective scoped to a team, location, or department"Durability Testing (Site A)"
Usage PlanTime-bound execution schedule within a work package"Spring Usage Plan (Site A)"

Work packages are the primary unit for separating scope. Because each work package has its own requests, allocations, usage plans, and documents, it acts as a natural boundary between teams, locations, or test objectives within the same project.

For a full explanation of each concept and how data flows between them, see Key Concepts.

Common Patterns

Choose the tab below that best matches your organisation's structure.

One team, one location, one vehicle programme at a time.

This is the simplest setup. You have a small fleet team running tests at a single site.

  • One workspace for the company or department.
  • One project per vehicle programme or model year.
  • One work package per test objective (durability, climate, emissions, etc.).
  • One usage plan per scheduling period (quarterly, seasonal, or campaign-based).

Same company, but testing happens at geographically separate sites — internal labs, proving grounds, or external suppliers.

  • One workspace for the company.
  • One project per vehicle programme.
  • One work package per location (or per location + test objective combination). This keeps each site's vehicles, drivers, shifts, and documents self-contained.
  • Usage plans within each work package cover time-based scheduling (seasonal, quarterly).

This pattern works well when each location has its own drivers and day-to-day management, even if the overall test goals come from a central team.

A group with distinct brands or divisions, each running their own vehicle programmes across shared or separate test facilities.

  • One workspace for the company or group. All brands, departments, and locations share the same pool of vehicles, drivers, and resources.
  • One project per brand + vehicle programme (e.g. "Brand A - Model X BEV", "Brand B - Model Y 2027").
  • Work packages split by location or department within each project. Different departments (durability, NVH, climate) and different test sites each get their own work packages, keeping scope and day-to-day management separate while still sharing resources.
  • Usage plans within each work package cover seasonal or campaign-based scheduling.

If brands operate completely independently with no shared vehicles or drivers, consider separate workspaces per brand instead. Use a single workspace when there is cross-brand coordination or shared resources.

Example: Multi-Brand Automotive Group

To see how these patterns combine in practice, consider a vehicle manufacturer group onboarding onto Fleetwise.

The scenario

  • 4-5 brands under one corporate group, each with active vehicle programmes.
  • Multiple departments need to test vehicles (durability, NVH, climate, etc.).
  • 3 test locations: two internal sites (HQ and a regional facility) and one external testing supplier.
  • Test drivers are assigned to locations but occasionally shared between sites.
  • Vehicles and drivers are shared resources across departments and brands.

The structure

The group creates a single workspace for the company. Each brand + vehicle programme combination becomes a project. Within each project, work packages separate testing by department and location — so the durability team at HQ has its own work package, as does the NVH team at the same site.

Why this works

  • The workspace is the company. All brands, departments, and locations operate under one roof, sharing the same pool of vehicles, drivers, and resources.
  • Projects separate brands and vehicle programmes. Each brand's team sees only the projects they are members of.
  • Work packages separate departments and locations. The durability team at HQ has its own work package; the NVH team at the same site has another. Each work package contains only the requests, documents, and usage plans relevant to that scope.
  • Usage plans match real scheduling cycles. Seasonal plans (winter, spring, summer) align with how testing is actually scheduled — different locations may run different seasons depending on climate and facility availability.
  • Shared drivers work naturally. Because everything lives in one workspace, a test driver can be added to usage plans across multiple projects, departments, and work packages without duplicating their profile.

Coming Soon: Team-Based Visibility

Fleetwise is adding the ability to link work packages to teams. Once available, you will be able to restrict work package visibility so that users only see work packages assigned to their team — for example, the HQ team sees only HQ work packages. You can also add individual users for cross-team access. Currently, access is controlled at the project membership level.

Tips for Deciding

When to split workspaces

If divisions operate fully independently with no shared vehicles, drivers, or coordination, consider separate workspaces. Use a single workspace when there is cross-division collaboration or shared resources.

When to split projects

If brands or vehicle programmes have entirely separate vehicle pools and team members, make them separate projects. This gives each programme its own dashboard, schedule view, and access controls.

When to split work packages

If different groups of people manage different test objectives independently, or if testing happens at different physical sites with different drivers, create separate work packages. Name them by location, department, or objective to keep things clear.

How to scope usage plans

Usage plans map to scheduling cycles. Create one per time period that makes sense for your operation — seasonal, quarterly, or per test campaign. Each plan lives inside a work package and schedules the drivers and vehicles assigned to that scope.

On this page