How to Onboard a New Client Across Stripe, NetSuite, and Monday from a Signed Proposal

When a proposal is signed, a single Spojit workflow fans out to create the billing customer in Stripe, the customer record in NetSuite, a project board item in Monday.com, and a kickoff email, all in one onboarding run.

What This Integration Does

For a professional services firm, the gap between "the client signed" and "the client is actually set up" is full of manual steps: someone has to add them to billing, someone has to create the accounting record, someone has to spin up a project board, and someone has to send the welcome note. Each handoff is a chance to forget a step or transpose a number. This Spojit workflow collapses all of it into one automatic onboarding run, triggered the moment your proposal or e-signature tool reports a signature, so a new client is consistently set up in every system within seconds.

The run model is webhook-driven. Your proposal platform sends an HTTP POST to a Spojit Webhook trigger when a deal is signed. A Transform node normalizes the incoming payload into a clean client record, then a Parallel node fans that record out into three concurrent branches: one creates the Stripe customer, one creates the NetSuite customer, and one creates the Monday.com board item. After the branches finish, a Send Email node sends the kickoff message. The workflow leaves a billing customer, an accounting record, and a project item in place, and the run finishes async (the webhook returns immediately with an execution id). Because most upstream tools fire a signature event once, re-runs are rare; if a duplicate ever arrives, the Tips below show how to keep it from creating a second set of records.

Prerequisites

A Stripe connection in Spojit (API key), added via Connections → Add connection, with permission to create customers.
A NetSuite connection with access to create customer records, including the internal id of the subsidiary you assign new customers to.
A Monday.com connection, plus the boardId of your client onboarding board and (optionally) the groupId of the group new clients land in. Note the column ids on that board for fields like status or owner.
A Webhook signing connection so Spojit can verify the proposal tool's requests (scheme Custom if your tool signs with an HMAC secret, or Spojit for a simple shared secret).
Your team's kickoff email recipients added to the org allowlist under Settings → General → Email recipients if any are external addresses.

Step 1: Receive the signed proposal with a Webhook trigger

Create a new workflow and set the Trigger node type to Webhook. Spojit gives the workflow a URL; paste that URL into your proposal or e-signature tool's outbound webhook settings and point it at the "proposal signed" event. Select your signing connection so Spojit verifies each request, and choose the matching scheme. The trigger output is the parsed JSON body, available downstream as {{ input }}. A typical signed-proposal payload looks like this:

{
  "event": "proposal.signed",
  "client": {
    "company": "Northwind Consulting",
    "contactName": "Dana Reyes",
    "email": "dana@northwind.example",
    "phone": "+1-202-555-0143"
  },
  "proposal": {
    "id": "PRP-4821",
    "title": "Q3 Brand Refresh",
    "value": 18000,
    "currency": "usd"
  }
}

Step 2: Normalize the payload with a Transform node

Add a Transform node so every downstream branch reads from one clean shape instead of reaching into the raw webhook body. Map the incoming fields into a tidy client record and set the output variable to client:

{
  "company": "{{ input.client.company }}",
  "contactName": "{{ input.client.contactName }}",
  "email": "{{ input.client.email }}",
  "phone": "{{ input.client.phone }}",
  "projectTitle": "{{ input.proposal.title }}",
  "proposalId": "{{ input.proposal.id }}",
  "dealValue": "{{ input.proposal.value }}",
  "currency": "{{ input.proposal.currency }}"
}

Now the rest of the workflow uses {{ client.company }}, {{ client.email }}, and so on, which keeps each connector mapping short and readable.

Step 3: Fan out with a Parallel node

Add a Parallel node after the Transform node and give it three branches. The three systems do not depend on each other, so running them concurrently means the whole onboarding finishes as fast as the slowest single call rather than the sum of all three. Each branch will hold one Connector node in Direct mode, which is the deterministic, no-AI-cost option: you pick exactly one tool and map its inputs. The branches are described in Steps 4 through 6.

Step 4: Create the billing customer in Stripe

In the first parallel branch, add a Connector node on the Stripe connector in Direct mode and choose the create-customer tool. Map the fields from your normalized record:

name: {{ client.company }}
email: {{ client.email }}
phone: {{ client.phone }}
description: {{ client.projectTitle }}
metadata: a key-value map carrying the source proposal, for example proposalId = {{ client.proposalId }}

Set the output variable to stripeCustomer. The created customer id is then available as {{ stripeCustomer.result.id }} for the kickoff email or any later billing step.

Step 5: Create the customer record in NetSuite

In the second parallel branch, add a Connector node on the NetSuite connector in Direct mode and choose the create-customer tool. NetSuite takes a single body object holding the customer payload, so map your record into it:

{
  "companyName": "{{ client.company }}",
  "email": "{{ client.email }}",
  "phone": "{{ client.phone }}",
  "subsidiary": { "id": "1" },
  "isPerson": false
}

Replace the subsidiary.id with the internal id you noted in the prerequisites. Set the output variable to netsuiteCustomer. If you prefer that re-running the workflow never creates a duplicate accounting record, use the upsert-record tool instead and key it on an external id you control (such as the proposal id).

Step 6: Create the project board item in Monday.com

In the third parallel branch, add a Connector node on the Monday.com connector in Direct mode and choose the create-item tool. Map:

boardId: your onboarding board id from the prerequisites
name: {{ client.company }} - {{ client.projectTitle }}
groupId: the group new clients should land in (optional)
columnValues: a structured object keyed by your board's column ids, for example a status column set to "Onboarding" and a text column holding {{ client.contactName }}

Set the output variable to mondayItem. The new item id is available as {{ mondayItem.result.id }} if you want to reference the board card in the kickoff email.

Step 7: Send the kickoff email

After the Parallel node, add a Send Email node so the email only goes out once all three records exist. It sends from Spojit's built-in mail service with no extra connection. Configure:

Recipients: your delivery lead plus, if you want, {{ client.email }}
Subject: Kickoff: {{ client.company }} - {{ client.projectTitle }}
Body: a short plain-text note confirming the client is set up, for example "Northwind Consulting is now onboarded. Stripe customer {{ stripeCustomer.result.id }} and the Monday board item are ready."
If sending fails: choose Continue anyway so a mail hiccup does not undo the records you already created.

If you would rather send from your own domain than the built-in service, swap the Send Email node for a Connector node on the Resend connector using send-email, or the SMTP connector using send-email. To also post a heads-up to your delivery team's channel, add a Connector node on the Slack connector with the send-message tool in the same final stretch of the workflow.

Tips

Keep each branch a single Direct mode call. It is deterministic, costs no AI credits, and makes the run easy to read in the execution log.
Stripe stores amounts in the smallest currency unit. You are only creating a customer here, but if you later add a create-invoice step, multiply {{ client.dealValue }} by 100 in a Transform node first.
Stash the proposal id in Stripe metadata and (via upsert-record) in NetSuite so every record traces back to the deal that created it.
Building this for the first time? Ask Miraxa, the intelligent layer across your automation, "Add a Parallel node after my Transform node with three branches, each a Connector node in Direct mode for Stripe create-customer, NetSuite create-customer, and Monday create-item." It scaffolds the canvas, then you fine-tune the field mappings in the properties panel.

Common Pitfalls

Duplicate signature events. Some proposal tools retry webhooks. Turn on the trigger's opt-in deduplication using the tool's event-id header so a replayed delivery does not create a second set of customers, or use upsert-record in the NetSuite branch keyed on the proposal id.
Monday column ids vs labels. The columnValues object is keyed by column id, not the column's display name, and status columns expect the label text. Open the board's column settings to confirm ids before mapping.
NetSuite subsidiary required. On OneWorld accounts the subsidiary field is mandatory; leaving it out makes create-customer fail. Hardcode the correct internal id.
External email recipients. The Send Email node only delivers to addresses on your org allowlist. Add the client's domain under Settings → General → Email recipients first, or the message is blocked.

Testing

Before pointing the live signature event at the workflow, validate on a small scope. Use a test board in Monday.com and a sandbox or test-mode Stripe and NetSuite connection, then send one sample signed-proposal payload to the webhook URL (your proposal tool's "send test event" button, or any HTTP client). Watch the run in the execution log: confirm the Transform node produced a clean client object, that all three Parallel branches succeeded, and that the kickoff email arrived. Open Stripe, NetSuite, and the Monday board to verify one record exists in each with the right names. Once a single end-to-end pass looks correct, switch the connections to production and enable the workflow.