Check access before building the board.

Projects is included on Premium and Ultimate; Lite and Growth use a paid add-on. Creating and editing projects requires the relevant app access as well as access to Deals. Someone may see linked project information without being able to edit it.

Ask your account administrator to confirm the existing entitlement. Do not enable a trial or add seats just to follow this example. Use fictional records in an approved internal location and check that both people can open the linked scope.

Pipedrive: Projects access and billing

Check the current plan and user access before changing settings.

1. Set up the receiving work

Create a delivery board with a review phase.

01
Create the internal board
In Projects, open the board selector and choose + New board. Name this example Small onboarding. Leave established boards unchanged.
02
Use a short sequence of phases
For this example, use Review scope, Plan kickoff, Delivery and Close out. These names are proposed team choices, not Pipedrive defaults. Keep a project in Review scope while a material question remains.
03
Create or link the project from the deal
Inspect the deal’s Projects panel for an existing link first. Pipedrive documents a Mark as won and create a project option at close and a sidebar route to create or link a project. Use the appropriate route for the current deal state; do not change a real win date or create another project just to repeat the example.
04
Check the link and receiving owner
Name the example D-418 / Cedar Demo onboarding. Verify the deal reference and choose Alex as project owner. Open the linked deal from the project before adding work. Confirm the scope reference is accessible under Alex’s permissions.

Create the internal board
In Projects, open the board selector and choose + New board. Name this example Small onboarding. Leave established boards unchanged.
Use a short sequence of phases
For this example, use Review scope, Plan kickoff, Delivery and Close out. These names are proposed team choices, not Pipedrive defaults. Keep a project in Review scope while a material question remains.
Create or link the project from the deal
Inspect the deal’s Projects panel for an existing link first. Pipedrive documents a Mark as won and create a project option at close and a sidebar route to create or link a project. Use the appropriate route for the current deal state; do not change a real win date or create another project just to repeat the example.
Check the link and receiving owner
Name the example D-418 / Cedar Demo onboarding. Verify the deal reference and choose Alex as project owner. Open the linked deal from the project before adding work. Confirm the scope reference is accessible under Alex’s permissions.

Keep the deal and the delivery review distinct.

Pipedrive supports deal-linked projects on boards with phases. In this example, a missing delivery dependency leaves the deal commercially won while Sales supplies the missing detail. If the sale itself was recorded incorrectly, follow the team’s separate correction process.

The project phase is a working convention. It is not proof that a reviewer checked the scope, and this setup does not prevent someone moving a card early.

Pipedrive: boards and deal-linked projects

Check the current creation routes and native project structure.

Decide what the receiving team needs

Use the wider handoff method to choose the scope and responsibilities.

2. Build a small template

Start with the work that repeats.

01
Create a template on the board
Go to Projects > Templates and choose + Template. Select Small onboarding and give the template a name that distinguishes it from a customer project.
02
Add the review and planning work
Use the proposed work below as a starting point. Keep customer-specific promises out of the reusable text. Name the person who will check each item when the template is used.
03
Set and inspect relative due dates
Templates can schedule work relative to a start date. Choose offsets that reflect your coverage, then inspect the actual generated dates on the fictional project. An internal review deadline must not silently become a customer kickoff promise.
04
Save, then apply once to the test project
Use the template’s save control. For an existing project on the same board, open its menu and choose Use template. Inspect existing work first and record the start date used for the added plan.

Create a template on the board
Go to Projects > Templates and choose + Template. Select Small onboarding and give the template a name that distinguishes it from a customer project.
Add the review and planning work
Use the proposed work below as a starting point. Keep customer-specific promises out of the reusable text. Name the person who will check each item when the template is used.
Set and inspect relative due dates
Templates can schedule work relative to a start date. Choose offsets that reflect your coverage, then inspect the actual generated dates on the fictional project. An internal review deadline must not silently become a customer kickoff promise.
Save, then apply once to the test project
Use the template’s save control. For an existing project on the same board, open its menu and choose Use template. Inspect existing work first and record the start date used for the added plan.

Four work items for this fictional onboarding.

Review scope / Alex

Open the agreed scope reference and check the two-session limit. Record acceptance or a specific question before planning the customer kickoff.

Resolve access approver / Maya

Name who at Cedar Demo can approve system access. If the name is unknown, leave the question visible and agree the next internal check.

Arrange kickoff / Alex

After the review, agree the customer date and participants. Do not treat the template’s provisional schedule as an invitation already sent.

Prepare the two sessions / Alex

Plan the agreed work from the scope. A new request for migration goes back for a commercial decision; it is not silently added to this onboarding.

Applying a template does not clear the existing plan.

Pipedrive says existing work items remain when a template is applied. The selected date schedules the added items but does not change the existing project start date. Check both before relying on the plan.

If the button was used twice, inspect the added work with the owner. Do not bulk-delete tasks that may already contain notes or completed work. This guide installs no uniqueness check; an agreed deal reference and a manual search are review aids.

Pipedrive: templates and scheduling rules

Verify relative dates and applying templates to an existing project.

3. Walk D-418 through review

Keep the access question with the project.

01
Maya submits the linked scope
The deal is won and the project is in Review scope. Maya points Alex to the agreed two-session scope. No kickoff date has been promised.
02
Alex records the gap
Alex leaves a project note: Access approver is missing; Maya to confirm before kickoff planning. The receiving review stays open. Completing the project-creation action does not complete this review.
03
Maya supplies the answer
Maya adds the approved contact reference and tells Alex where it is recorded. They keep the original question and the response in the same project.
04
Alex accepts the reviewed scope
Alex checks the reference, records acceptance with the scope version and date, completes the review work and moves the project to Plan kickoff. Delivery is still ahead. A later material scope change gets another review.

Maya submits the linked scope
The deal is won and the project is in Review scope. Maya points Alex to the agreed two-session scope. No kickoff date has been promised.
Alex records the gap
Alex leaves a project note: Access approver is missing; Maya to confirm before kickoff planning. The receiving review stays open. Completing the project-creation action does not complete this review.
Maya supplies the answer
Maya adds the approved contact reference and tells Alex where it is recorded. They keep the original question and the response in the same project.
Alex accepts the reviewed scope
Alex checks the reference, records acceptance with the scope version and date, completes the review work and moves the project to Plan kickoff. Delivery is still ahead. A later material scope change gets another review.

Try these cases before using customer records.

These are proposed checks, not completed Pipedrive test results. Use the permissions of the people who will do the work.

The deal already has a project

Find the intended project and inspect its work. Do not create a second transfer merely because the deal is opened again.

A reviewer cannot edit or open the scope

Record the access problem. An administrator reviews the appropriate access; the reviewer does not accept unseen commitments.

The project already has tasks

Apply the template only after checking what exists. Verify the resulting item count and dates, including the unchanged project start date.

The access approver is unknown

Keep the review open with a next-action owner and internal deadline. Check that nobody mistakes the phase for enforced approval.

Choose automation after the manual project works.

Stop the first trial when another authorised person can follow the link, find the open question and explain the next action. Decide separately whether automatic project creation is useful; duplicate handling and failure recovery need their own design.

If delivery already belongs in another tool, keep that decision. A linked Pipedrive project is useful only when the people doing the work can maintain it.

Set up the receiving work in ClickUp instead

An alternative when the delivery queue lives outside Pipedrive.

Workflow automation for commercial teams

Place this small implementation inside the wider operating process.

The deal is won. Delivery still has a question.

Create a delivery board with a review phase.

Create the internal board

Use a short sequence of phases

Create or link the project from the deal

Check the link and receiving owner