Product

Workflow action

The action sits in your CRM's workflow builder alongside the ones already there. A workflow that reaches it produces a document and carries the link forward.

What makes it native

A neighbouring PDF API can be called from your CRM, through a webhook step and something to shape the payload. This is a stepinside it: you add Generate PDF the same way you add Send Email, and there is no plumbing between the two.

Setting one up

  1. Add the Generate PDF action to a workflow.
  2. Pick a template. The action loads the list from your workspace, so it shows the templates you actually have.
  3. Map the data the template reads. The contact is supplied automatically; map an Invoice ID for documents with line items, or anOpportunity ID for documents with a deal. Anything you leave blank is simply left off the page.
  4. Optionally set an Element ID so a retried run returns the same document instead of a duplicate.

You never hand-write the payload. The action pulls the contact, deal, invoice and business details from the CRM itself at generation time — the workflow only points it at the right template and records.

What comes back

The action returns a download URL, the document number and the request id. Later steps in the same workflow can use the URL directly — attach it to an email, write it to a custom field, send it to the contact.

Triggering without the builder

The workflow action is one of three ways in. The others are theREST API for your own systems andbatch jobs for a cohort at a time.

How it authenticates

Workflow-action calls carry no API key or signature — GHL identifies your workspace by its location id. The action verifies an active installation for that workspace, then reads all data with its own stored OAuth token, so nothing sensitive travels through the workflow payload.