How to Notify a Slack Channel When a New Front Contact Is Created

Catch every new contact created in Front, enrich it with full profile details, and post a clean welcome notification to a Slack onboarding channel so your team greets each person the moment they land.

What This Integration Does

When a new person reaches your support inbox for the first time, Front creates a contact record. Your onboarding, success, or sales team usually wants to know right away so they can assign an owner, send a personal hello, or kick off a welcome sequence. This Spojit workflow watches for those new Front contacts, pulls the full profile so the message is rich (name, handles, description), and drops a formatted notification into a dedicated Slack channel. No one has to keep refreshing Front to spot newcomers.

The workflow runs on a Webhook trigger: Front sends an HTTP POST to Spojit whenever a contact is created. Spojit parses the event body, uses the contact ID inside it to fetch the complete contact record from Front, then posts one message to Slack. Each event runs independently, so a burst of new contacts produces a burst of notifications. There is no stored state between runs, and re-delivery of the same event simply posts again unless you enable webhook deduplication on the trigger.

Prerequisites

A Front connection with permission to read contacts (the get-contact tool). See the Front connector reference.
A Slack connection whose app is a member of the channel you want to post to, with permission to send messages. See the Slack connector reference.
A signing connection for the Webhook trigger so Spojit can verify that requests genuinely come from Front. Use a Custom scheme if you are validating a shared secret, or no verification while you test. See Setting Up a Webhook Trigger.
The Slack channel ID of your onboarding channel (for example C0123456789), which you can copy from the channel details in Slack.
Access to Front's settings so you can register an outbound webhook rule that fires on contact creation.

Step 1: Add a Webhook trigger

Create a new workflow in the Spojit designer and set the Trigger node type to Webhook. Spojit assigns the workflow a unique URL. Attach a signing connection so incoming requests are verified by HMAC; pick the Custom scheme if you are checking a shared secret from Front, otherwise leave verification off only while testing. The trigger returns 202 with an executionId to Front as soon as it accepts the event. The parsed JSON body is available to later steps as {{ input }}.

Step 2: Register the webhook in Front

In Front, create a webhook (or a rule with a webhook action) that fires when a contact is created, and point it at the workflow URL from Step 1. Front delivers an event payload that contains the new contact's ID. A typical event exposes the contact reference like this, which you will read in the next step:

{
  "type": "contact",
  "payload": {
    "id": "crd_1a2b3c",
    "name": "Jordan Rivera"
  }
}

Field paths can vary by Front configuration, so open one real delivery in the run's execution log to confirm exactly where the contact ID sits before you wire it up.

Step 3: Enrich the contact from Front

Add a Connector node in Direct mode, choose the Front connector, and select the get-contact tool. Map its single input id to the contact ID from the trigger, for example {{ input.payload.id }} (adjust the path to match what you saw in Step 2). Direct mode is the right choice here because this is one predictable lookup with no AI cost. Set the node's output variable to something like contact so the full record, including name, handles, and description, is available downstream as {{ contact }}.

Step 4: Shape the notification text

Add a Transform node to assemble a tidy summary string from the enriched contact. Pull out the fields you want to surface, such as the display name, the primary email handle, and the description, and combine them into a single message body. For example, build a value like:

New Front contact: {{ contact.name }}
Email: {{ contact.handles.0.handle }}
Notes: {{ contact.description }}

If a contact arrives without a name or description, provide a fallback in the Transform so the message still reads cleanly rather than printing an empty line. Store the result in a variable like summary.

Step 5: Post the welcome notification to Slack

Add a second Connector node in Direct mode, choose the Slack connector, and select the send-message tool. Set channel to your onboarding channel ID (for example C0123456789) and set text to the summary you built, for example {{ summary }}. The text value also acts as the fallback for notifications and accessibility, so always fill it even if you add richer formatting later. The node returns the posted message details, which you can keep for logging.

Step 6: Add rich formatting (optional)

If you want a card-style notification instead of plain text, the send-message tool also accepts an optional blocks field for Block Kit layout. Provide a JSON array of block objects to render a header, the contact's details as fields, and a divider. Keep the text field populated as the plain fallback. For a first build, plain text is perfectly readable, so treat blocks as a polish step once the core flow works.

Tips

Use Direct mode for both connector calls. The lookup and the post are deterministic single-tool actions, so there is no need to spend AI credits on Agent mode here.
Open the most recent delivery in the execution log to copy the exact contact-ID path from Front before mapping id. Front payload shapes differ between rule-based and app-based webhooks.
To greet contacts in a thread or keep channel noise down, you can route all notifications to one channel and rely on Slack's own threading, or post a daily digest by batching with a Schedule trigger instead of per-event delivery.
Confirm the Slack app is actually a member of the target channel. Posting to a channel the app has not joined fails even when the connection is valid.

Common Pitfalls

Duplicate notifications. Webhook re-deliveries post the same contact twice. Enable the trigger's opt-in deduplication via an event-id header from Front so replays are ignored.
Missing handles. A brand-new contact may have only one handle, or the array order may differ. Reference handles defensively in the Transform and add a fallback so {{ contact.handles.0.handle }} never breaks the message.
Wrong channel target. Slack's channel expects a channel ID, not the display name. Copy the ID (it starts with C) from the channel details rather than typing #onboarding.
Reading the wrong field. If get-contact returns an empty record, the ID you mapped probably points at the event wrapper rather than the contact's own ID. Re-check the payload path against a real delivery.

Testing

Before pointing production traffic at the workflow, validate on a small scope. Create a single test contact in Front (or temporarily disable signature verification and replay one captured event body against the workflow URL). Run it once, open the execution log in Spojit, and confirm three things: the trigger parsed the contact ID, the get-contact step returned a full record under {{ contact }}, and Slack received exactly one message in the right channel. Once a single contact flows end to end, turn the Front webhook on for all new contacts and re-enable signature verification.