Skip to main content
Kantata support is coming soon. The pages below describe how it will work — get in touch if you want early access.
If your services team runs in Kantata (formerly Mavenlink) and your CS team runs in Thread, the gap between “deal closed” and “project staffed” is where weeks get lost. Connecting Kantata closes it: the moment Closed Won fires, Thread can stand up the project, allocate hours by role, and hand the PM a ready-to-run delivery plan.
Workflow builder with a Salesforce trigger feeding into a Create Kantata Project action node, with role and hour allocation in the inspector panel

​
What you can build

Customer kickoff & onboarding

A single workflow that spins up the Kantata project, applies the success plan, and books the kickoff call.

CSM assignment

Resource consultants by role and availability — not by who replied first to a Slack message.

Success plans

Keep the Kantata project plan and the Thread success plan in sync so customers see one truth.

Customer handover

Hand the PM a project that already knows the scope, owner and exec context.

​
Connect Kantata

1

Open Connectors → Kantata → Connect

Go to Connectors → Kantata in Thread, click Connect, and sign in to Kantata as an account admin to approve the OAuth scope. Thread connects via the legacy app.mavenlink.com OAuth domain — that’s expected; Kantata still uses the Mavenlink OAuth host.
2

Pick a default project template

Under Connectors → Kantata, choose which Kantata project template Thread instantiates by default. You can override per-workflow.
3

Map roles to your resourcing model

Tell Thread which Kantata roles correspond to “Solutions Architect”, “Project Manager”, “Implementation Engineer” etc. so role-based allocations apply correctly when projects are created.

​
Use Kantata in a workflow

Drop a Create Kantata project action node anywhere downstream of an account-creating trigger. The node takes:
FieldWhat it does
Project templateThe Kantata template to clone from (e.g. “Standard implementation”).
Project nameSupports variables — {{ account.name }} — Implementation is the common pattern.
Resource roles & hoursHours per role; Kantata resourcing then assigns specific consultants by availability.
Linked opportunityAuto-set from the Salesforce trigger upstream. Lives on the project for traceability.
A common pattern: gate the action on a services hours > 0 branch off the Salesforce trigger, so non-services deals don’t accidentally create empty Kantata projects.

​
Tips from the field

One template per segment

Enterprise vs SMB usually need different role mixes. Branch by ARR and pick the template up front.

Map roles, not people

Role-based allocations survive team changes. Hardcoded names don’t.

Link to Salesforce

The opportunity link lives on the Kantata project so finance and delivery share one ID.

Notify the PM

Add a Slack or email handover step right after project creation so the PM isn’t surprised.

​
Troubleshooting

Confirm the Kantata client ID configured for your environment matches the OAuth app you’re authorizing against. Sandbox/staging Kantata accounts need a separate client ID.
Role mappings haven’t been set, or the roles in the Kantata template don’t match what Thread is sending. Check Connectors → Kantata → Role mapping.
Disconnecting stops new project creation but does not affect existing Kantata projects. Tokens are revoked from Kantata’s side; reconnect from Connectors → Kantata to restore the integration.

​
Next steps

Customer kickoff & onboarding

The full services-handoff workflow, from Closed Won to staffed project.

Salesforce

The most common upstream trigger for Kantata project creation.