Getting started with Developer Lifecycle Management

Developer Lifecycle Management (DLM) is the Partner Fleet module for onboarding, reviewing, and activating technology partners end-to-end. It replaces the email, spreadsheet, and Slack thread chaos that most partner programs default to. Your partners move through a single self-serve workflow. Your team manages everything from one dashboard.

This guide covers what DLM does, the building blocks you'll configure, and how to stand up your first developer pipeline. If you're upgrading from an older partner onboarding process or migrating from another tool, start here.

---

Prerequisites

Before you configure DLM, make sure you have:

• An active Partner Fleet account with the DLM module enabled
• Admin access to your Partner Fleet instance
• A rough sketch of your partner program stages (the Designing your first pipeline section below walks through this)

If you plan to extend DLM into external systems with webhooks (DocuSign, Salesforce, Jira, ServiceNow, etc.), you also need admin access to those systems to configure the receiving endpoints.

---

What DLM does

DLM gives you two surfaces that work together:

For your partners — the Partner Portal. A branded, self-serve portal where prospective and active developers can apply to your program, see exactly where they are in the process, complete each step (sign agreements, submit an app, request credentials, build a listing), and track progress without emailing your team. Every partner sees their own personalized journey.

For your team — the admin pipeline view. A Kanban or list view of every partner moving through your program. Click into any project card to see who's stuck where, leave internal notes, trigger the next step, or impersonate the partner's view to see exactly what they're seeing. Filter by tags, search by status, export to share with leadership.

The whole thing is built around Pipelines — visual workflows you configure to match the way your program actually runs.

---

How DLM fits your program

DLM is intentionally flexible. The same module supports a five-person partner program with a lightweight intake form. It also supports a 500-partner ecosystem with a multi-team approval workflow that extends into Salesforce, DocuSign, Jira, ServiceNow, and beyond.

Every program runs on the same foundation. Native pipeline steps and automations handle the workflow inside Partner Fleet. Webhooks extend that workflow into the tools your team already uses — DocuSign for agreements, Salesforce for partner records, Drata or ServiceNow for security review, Jira for engineering tickets. Pipeline stages remain the source of truth for partner status, and the work happens wherever it makes the most sense.

---

The building blocks

Five concepts power every DLM configuration. Understanding how they connect is the most important thing to take away from this doc.

1. Pipelines

A Pipeline is a workflow. Each pipeline represents one type of partner journey — for example, "ISV onboarding," "Agency partner onboarding," or "MCP server registration." Create as many pipelines as your program needs. Partners can appear in more than one.

Create a pipeline from Pipelines → New Pipeline. Name it, then start adding steps.

2. Steps

A Step is a single stage of a pipeline. Steps appear as columns in the Kanban view and define what the partner sees and does at that moment in their journey. A typical onboarding pipeline has between 5 and 8 steps — we recommend starting on the lower end. You can always add steps later.

For each step, you can configure:

• Name — what the partner sees (e.g., "Sign agreement," "Build your integration")
• Description — context that appears in the Partner Portal
• Color — for visual scanning in the Kanban view
• Resources — docs, links, or files the partner can access at this step
• CTA button — the action the partner takes to move forward (e.g., "Create your listing")
• Roles & Permissions — what the partner can see and do while at this step

3. Projects

A Project is one partner's instance of a pipeline. When a partner is added to a pipeline, a project card is created and moves through the steps as the partner progresses.

Projects are tied to a Partner Account, which is created when the partner accepts their portal invite. A single account can have multiple projects — for example, a system integrator building three apps for your platform would have three projects in your "Integration build" pipeline.

From the project card you can:

• See account info, users on the account, recent activity, and "needs attention" flags
• Add Project Tags for filtering ("High value," "Q2 priority," "Stuck")
• Leave internal comments (not visible to the partner)
• Manually move the project between steps
• Click directly into a user and impersonate them to see exactly what they see in the portal

4. Apps

An App is a record of a partner's integration — the technical submission, not the marketplace listing. Apps serve two primary purposes:

• Capture integration metadata — scopes, endpoints, redirect URLs, authentication mechanism
• Run multi-step approval workflows — route submissions to the right reviewers (Product, InfoSec, Legal, Partnerships, or any other team that needs a say before an integration goes live)

Apps and listings are separate objects on purpose. A listing is the marketing-facing description of an integration that appears on your marketplace. An app is the technical record that goes through internal review. Automations link the two — for example, "when the app is approved, give the partner permission to create a listing."

Configure apps under Apps → App Fields (define what data you collect) and Apps → App Approval Forms (define how reviewers approve it, including multi-step approvals routed to different admin roles).

5. Automations

Automations connect the building blocks together. They're the "when X happens, do Y" rules that turn a static pipeline into a workflow.

Common automations:

• Form approved → Create project in Pipeline (this is how partners get into the pipeline from an application)
• Project enters Step → Send email to partner
• App approved → Assign role that unlocks listing creation
• Project enters Step → Fire a webhook to DocuSign, Jira, ServiceNow, or any other system
• Webhook received → Move project to next step

Set up automations under Pipelines → Automations. Each automation has a trigger, a pipeline it applies to, and an action.

---

Surfacing resources and API docs to partners

Most partner programs have a library of documentation that partners need at different points in their journey. This includes integration guides, API reference docs, brand assets, sample code, security questionnaires, partnership agreements, and sandbox setup instructions. DLM lets you make all of that available inside the Partner Portal, and surface the right resources at the right step of the pipeline.

You can attach resources at two levels:

• Globally, in the Partner Portal. Use folders (e.g., "Getting Started," "API Reference," "Brand Assets," "Legal") to organize content that any partner can access whenever they need it. This is the right home for evergreen docs your team maintains over time.
• Per pipeline step. Attach resources directly to a step so they appear in the Partner Portal exactly when the partner reaches that stage. A "Sign agreement" step might surface the MSA template. A "Build" step might surface API docs, OpenAPI specs, sample integrations, and links to your sandbox. A "Listing" step might surface brand guidelines and screenshot specs.

Step-level resources inherit the role configured on the step. This lets you gate sensitive content — production API docs, partner-only assets — behind the right pipeline stage. A partner in the Applicant role does not see resources scoped to Integration Partners.

If you maintain API docs in an external system like ReadMe, Stoplight, or your own developer portal, you can link out to those docs from a pipeline step rather than re-host the content. We also offer native API doc embedding — talk to your CSM if you'd like to learn more.

---

How the pieces fit together

Here's the flow most customer programs follow, end to end:

1. A prospective partner fills out a Partner Application form on your marketplace or website
2. An admin reviews the application under Forms → Submissions, then approves
3. An automation fires: Project created in the pipeline, invite email sent to the partner
4. Partner accepts the invite and lands in their Partner Portal, where they see Step 1 of their journey
5. Partner completes each step (signs an agreement, requests a sandbox, builds an integration, submits an App for review)
6. Each step transition can fire automations — internal notifications, webhook calls to external systems, role changes that unlock new capabilities
7. Once the app is approved, the partner builds and submits a listing, which goes through its own review
8. Listing is approved, integration goes live on your marketplace — the project reaches its terminal state

---

Designing your first pipeline

Before configuring anything in the admin, sketch your pipeline. The most common implementation mistake is starting with too many steps. Customers often arrive with 14-step processes — you can usually collapse those into 5 or 6 actual pipeline stages.

A good rule: one step per partner-visible outcome. If two consecutive stages don't change what the partner sees or does, they're the same step.

A solid starting template for most ISV programs:

Then ask: where in this flow do I need to involve another team or another tool? Those are your webhook candidates.

---

Configuration walkthrough

This section is the hands-on flow. Work through it in order the first time.

Step 1 — Create the pipeline

Navigate to Pipelines → New Pipeline. Give it a clear name ("ISV Onboarding," "Agency Partner Onboarding"). Pipelines are visible to your team, so name them how you'd describe them in a meeting.

Step 2 — Build out the steps

Click + Add Step for each stage in your sketch. For each step:

• Set the name, description, and color
• Add any resources the partner should have access to
• Set the CTA (optional, but recommended for any step where the partner needs to take an action)
• Configure the role on the step — this controls what the partner can see and do

You can reorder steps with the arrow controls, and you can edit steps at any time. Don't worry about getting it perfect on the first pass.

Step 3 — Configure roles and permissions

Go to Users → Roles & Permissions. Most customers need at least two partner-side roles:

• Applicant — the role assigned to brand-new partners during the application/review phase. Limited access.
• Integration Partner — the role assigned once the partner has signed an agreement and is actively building. Expanded access (can submit apps, create listings, etc.).

You'll also want at least one Admin role for your internal team. Multi-step app approvals use admin roles to route review to the right people, so create separate admin roles for InfoSec, Legal, Partnerships, etc. if your approval flow fans out.

Step 4 — Build the Partner Application form

Under Forms → Form Builder, create your partner application. This is the public-facing form that captures prospective partners and starts their journey.

Keep the form purposeful — every field is friction. Capture what you need to make a fit decision and nothing more. You can always collect additional details once the partner is in the portal.

Step 5 — Define your App (if applicable)

If your program reviews and approves technical integrations, configure apps under Apps:

1. App Fields — define the metadata you collect (scopes, endpoints, auth method, redirect URLs). These don't require approval to change.
2. App Approval Forms — define the submission form partners fill out. Fields here flow through approval.
3. Approval Steps — if you need multi-team review, configure each step in cadence (Step 2 only becomes available once Step 1 is approved). Assign each step to the admin role responsible.

Step 6 — Wire up automations

Go to Pipelines → Automations. At minimum, you'll want:

• Trigger: Partner Application form approved → Action: Create project in Pipeline at Step 1
• Trigger: Project enters [Agreement step] → Action: Send email with agreement link (or fire webhook to DocuSign)
• Trigger: App approved → Action: Assign Integration Partner role + move project to next step

Start with the bare minimum. Add automations as you watch the first few partners move through.

Step 7 — (Optional) Configure webhooks

If you're extending DLM into external systems, configure webhooks on the relevant automations.

Any system that can receive an incoming webhook from Partner Fleet will work — including DocuSign, Drata, ServiceNow, and Jira. We've fully tested firing webhooks into Jira to create tickets, and we have customer-validated patterns for DocuSign and ServiceNow.

The webhook payload Partner Fleet sends includes:

• id — automation ID
• name — approval form name
• pipe_object_id — pipeline project ID
• step_id — pipeline step ID
• state — current state
• created_at / updated_at — timestamps

If your receiving system can't act on a webhook directly, an intermediate layer like Zapier or n8n can bridge the gap. Reach out to your CSM if you're not sure whether you need one.

Step 8 — Test as a partner

This is the most underused feature in DLM: from any project card, click into a user and select Impersonate. You see the portal exactly as the partner does. Walk through the entire journey end to end before you invite your first real partner. This surfaces 90% of the configuration issues you would otherwise discover via partner complaint emails.

---

Managing partners day-to-day

Once your pipeline is live, here's how your team works in DLM.

The pipeline view

Kanban view is the default — every active partner shows as a card in the column matching their current step. Click a card to open the project detail panel.

List view (toggle in the top right) is better for bulk review and export. Export to CSV for sharing with leadership or for analysis outside the platform.

Use Project Tags to mark cards that need attention without moving them between steps. Common tags: "High value," "Stuck," "Needs follow-up," "VIP."

Working a project card

Open any project card to see:

• Account info — company, contact details, all users on the account
• Recent activity — timestamps for every step transition and automation that fired
• Internal comments — leave notes for your team (not visible to the partner)
• Manual controls — move the project forward or backward between steps if you need to

Impersonation

Click a user, then Impersonate. You'll see the Partner Portal as that user — same step, same CTAs, same resources, same blocked or unblocked features. End impersonation to return to your admin view.

Multi-app partners

A single partner account can have multiple projects in the same pipeline (e.g., one project per integration they're building). In the partner's view, they'll see a toggle between projects. In your view, the project cards appear separately on the Kanban board, both tied to the same account.

---

If you're interested in learning more about DLM or would like a live demo, reach out to your Customer Success Manager.