How to choose between native Forms and Custom Codes for lead capture

The short answer

Use the native Forms module for 90% of lead capture. Reach for Custom Codes only when:

• The third party (Mailchimp, HubSpot, Marketo) MUST own the data per your stack decision
• You need a form widget your CRM controls end-to-end
• You're embedding a calendly / typeform / chat-style flow that isn't a form at all

Default to native. The native form integrates with attribution, the audit log, notification routing, and the contact record automatically. A Custom-Codes-embedded third-party form is a black box from SGEN's view.

What is this for?

Most lead-capture work is a contact form, a newsletter signup, a download gate, or a quote request. SGEN ships a Forms module that handles all of these natively — with submission storage, email routing, attribution tagging, and audit logging built in.

But sometimes a CRM mandates "use OUR form" — and the temptation is to paste the iframe into Custom Codes and call it done. That works, but it loses everything SGEN's native module gives you for free.

This page is the decision rule.

Good use cases

• You're building a new SGEN site and choosing how to handle contact forms.
• You're rationalizing form vendors across an inherited site.
• You inherited a site with 5 different third-party form vendors embedded via Custom Codes.
• Your marketing team wants attribution data per form, and you don't know where it lives.
• You're evaluating moving from a CRM-hosted form to a native SGEN form.

Example 1 — Contact form, native: A team uses a native form for their "Get in touch" page. Submissions are stored in the admin → My Forms, attribution data (UTM + referrer) is auto-tagged, and the sales team gets email notifications. Zero Custom Codes involved.

Example 2 — Native + HubSpot hybrid: The e-commerce team uses HubSpot for lead nurturing. Their demo request form is a HubSpot embed via Custom Codes — HubSpot owns the lifecycle. Their newsletter signup, event RSVP, and contact forms are all native (no HubSpot lifecycle needed for those).

Example 3 — inherited site audit: A site was found with 5 different form vendors embedded via Custom Codes (Typeform, Mailchimp, HubSpot, a custom HTML form, and a Calendly). After audit: 3 migrated to native (contact, RSVP, newsletter). 2 kept as Custom Codes (HubSpot for sales, Calendly for booking). Attribution data went from 0% visibility to 80% coverage.

What NOT to use this for

• Don't replace your CRM with the Forms module. Forms captures the submission; your CRM/email tool does the downstream nurture.
• Don't use the Forms module for calendar booking or chat. Different tool category — those are appointment / messaging widgets, not forms.
• Don't embed a third-party form for a simple contact or newsletter form. Native handles these better. The only reason to embed is when the third-party owns something native can't give you.
• Don't assume "it works" means attribution is flowing. A form submitting successfully doesn't mean attribution data is populated. Verify in the admin → Attribution → by form after the first real submission.

How this connects to other features

• SG-Modules → Forms — the native form builder, submission storage, and notification routing
• SG-Modules → Attributions — how attribution tags (UTM + referrer) attach to form submissions automatically
• Custom Codes — where third-party form embeds live (iframe or script injection)
• SG-Builder → Components → Forms — the native form block for dropping a form into an SG-Builder page

Before you start

• Know whether your CRM team mandates using their own form embed (HubSpot, Marketo, Pardot). If yes, that's a Custom Codes case.
• Know which forms need attribution data (UTM tracking). Native forms get this for free; third-party embeds need manual hidden-field wiring.
• If auditing an existing site, list every form embed in Custom Codes before deciding what to migrate.

Where to find it

• Native Forms: the admin → My Forms → Create
• Form-as-block in SG-Builder: SG-Builder editor → Components → Forms → drop the Form block on a page, pick the form
• Custom Codes: the admin → Tools → Custom Codes (only for third-party embeds)
• Attribution view: the admin → Attribution → by form

Native vs third-party — capability table

The right question before embedding a third-party form: "Is the SGEN-side capability I'm giving up worth what the third-party gives me?" For 90% of forms, the answer is no.

The right question is: "Is the lost SGEN-side capability worth what the third-party gives me?" For 90% of forms, the answer is no.

For most teams: contact form, newsletter, event RSVP, and download gate are all native. Demo booking (Calendly) and sales inquiry (HubSpot) are Custom Codes embeds. That's the right balance.

When Custom-Codes-embed is right

There are real cases. Don't fight them.

1. Your CRM owns the lead lifecycle from form submit → MQL → close. HubSpot embedded forms, Marketo embedded forms, Pardot — these tools are designed to be the system of record. Use their embed.
2. You're using a specialized form tool with capability native Forms doesn't ship. Typeform's conditional logic, calendly's scheduling, Tally's payment integration. Use the third-party.
3. Your team has invested in custom form analytics in another tool. Switching costs > native benefit.
4. Legal / compliance requires the third-party. Sometimes a vendor mandates its own consent flow.

If you're in one of these, embed via Custom Codes. Document why in a comment in the Custom Codes block AND in your team's hybrid map document. The comment is the signal for the next person: "this isn't an oversight, it's intentional."

Comment convention to use in Custom Codes:

<!-- FORM: HubSpot sales inquiry embedReason: HubSpot owns the lead lifecycle (submit → MQL → close)Do not migrate to native without checking with the sales ops team.Last reviewed: 2026-05-26 by hello@yourteam.com -->

When native Forms is the obvious win

• Contact / sales-inquiry forms — almost always native.
• Newsletter signup — native if you're using SGEN's own email or a simple SMTP gateway.
• Download gates — native (gate the download with a form submission).
• Event RSVPs — native.
• Quote requests — native.
• Multi-step intake forms — native if SGEN's form builder covers the field types you need.
• Internal team forms (employee feedback, ops requests) — native.

The hybrid pattern

Most teams end up with a hybrid: native Forms for everything except 1-2 forms owned by the CRM.

That's normal and right. Don't force everything to one extreme.

What you lose when you embed via Custom Codes

• Attribution. Native Forms attaches the UTM + referrer + landing-page automatically. Embedded third-party forms need you to wire that manually with hidden fields, and the wiring drifts.
• Audit visibility. SGEN's audit log doesn't see submissions to a third-party iframe. If a customer asks "did my form go through," you check the third-party tool — not SGEN.
• Notification routing. Native forms can route by form, by content keyword, by submission count. Third-party forms route via the third-party's rules.
• Visual consistency. Embedded forms inherit the third-party's styling. Native forms inherit your design system.
• One audit surface. Native forms put everything in one query-able place. Third-party scatter splits the data.

Where to find it

• Native Forms: the admin → My Forms → Create
• Form-as-block in SG-Builder: SG-Builder editor → Components → Forms → drop the Form block on a page, pick the form
• Custom Codes: the admin → Tools → Custom Codes (only for third-party embeds)
• Attribution view: the admin → Attribution → by form

Steps to evaluate your current setup

Steps

1. List every form on your site

Open the admin → My Forms to see all native forms. Then audit every Custom Codes entry for embedded third-party form code. You should have a full list: form name, implementation type (native or third-party), and which third-party if applicable.

2. Evaluate each non-native form

For each third-party embed, ask: does the third-party NEED to own this? If the CRM owns the lead lifecycle from submit → MQL → close, keep it as a Custom Codes embed. If not, migrate to native.

3. Verify attribution on native forms

Check the admin → Attribution → recent submissions. For each native form, confirm UTM and referrer are captured. If UTM is empty, the source page is missing UTM parameters on the link that drives traffic to the form page.

4. Document the hybrid map

Create a one-page document: which forms are native, which are third-party embeds, and WHY. This prevents the next person from migrating something away from Custom Codes for the wrong reason.

5. Set a default for new forms

Write the rule: "Native Forms unless [X]." Fill in [X]: "unless the CRM owns the lifecycle" or "unless a specialized scheduling tool is needed." New team members should know the default without asking.

What success looks like

• Most lead-capture is native — submissions queryable in one place.
• Attribution data is consistent across native forms.
• Third-party embeds are deliberate, documented, and limited to genuine CRM-owns-lifecycle cases.
• Your team's runbook has a one-sentence rule for new forms.
• New forms default to native without needing to discuss each one.

What to do if it does not work

"My native form submissions aren't showing up in HubSpot." Native forms don't auto-push to HubSpot. Wire a webhook (the admin → Forms → form settings → Webhooks) or sync via the HubSpot integration if installed.

"My third-party embed broke after a SGEN update." Third-party embeds via Custom Codes have no SGEN-side fallback. Check the third-party tool's status and confirm the embed snippet hasn't changed.

"I can't style my embedded third-party form." Iframe-based embeds limit styling. Most CRMs offer a "styled" embed mode — check the third-party docs. If unstyled is unworkable, evaluate moving to native.

"My attribution data is empty for native forms." The traffic source is likely missing UTM parameters on the links driving visitors to the form page. Fix the UTMs on the source campaigns; attribution on future submissions will populate.

Native Forms capability detail

What native Forms stores automatically

For every submission to a native form, SGEN stores:

• Submission data — all field values, timestamp, submission ID
• UTM parameters — source, medium, campaign, term, content (from URL at time of submission)
• Referrer — the page the visitor came from before landing on the form page
• Landing page — the URL where the form was submitted
• Device type — desktop, tablet, or mobile

This data is queryable per form in the admin → Attribution → by form. It does not require any setup — it's automatic for every native form.

A Custom-Codes-embedded third-party form captures none of this on the SGEN side. You'd need to wire it manually with hidden fields populated by your own tracking script.

Notification routing

Native forms can route submission notifications to:

• A fixed email address (most common)
• Multiple email addresses
• Different emails based on form field values (e.g., "route to sales@ if company size > 50, route to team@ otherwise")
• Webhook destinations (for CRM sync or Zapier)

Third-party forms route through their own platform rules.

Spam mitigation

Native forms include:

• Honeypot field (invisible to users, detected bot submissions fill it)
• Rate limiting per IP (prevents submission floods)
• Optional CAPTCHA (configurable per form)

Third-party forms provide their own spam protection, which varies by vendor.

Custom Codes embed — when it's right

There are real cases. Don't fight them.

In all other cases: native Forms.

Form-as-block in SG-Builder

For any page built in SG-Builder (homepage, landing pages, product pages), native forms are available as a drag-and-drop block:

1. Open the page in SG-Builder
2. Components panel → Forms → drag the Form block onto the canvas
3. In the right-side panel, select which form to embed (dropdown of all forms in "My Forms")
4. The form inherits the page's design system — colors, typography, button styles

This means native forms render with visual consistency to the rest of the page. Custom-Codes-embedded third-party forms inherit the third-party's visual style, which rarely matches.

Attribution gap — what you lose with third-party embeds

The most common attribution gap: a campaign drives 500 visitors to a landing page. 40 submit the form. The question is "which campaign drove the submissions?"

• Native form: UTM captured per submission. Answer in the admin → Attribution → by form. Zero extra setup.
• Custom-Codes third-party form: UTM not captured by SGEN. You'd need to wire hidden fields populated by a tracking script before the form loads, and the third-party tool needs to expose those fields in its reporting. Fragile, drifts.

For most teams, this attribution gap is the deciding factor. If you need attribution data per form submission (and you almost always do for lead-capture forms), use native Forms.

Hybrid map template

Document your site's form implementation in your ops runbook. Copy and fill in:

Form: Contact formImplementation: Native (admin → My Forms → "Contact Us")Route: submissions → hello@yourteam.comAttribution: activeReason: No CRM lifecycle needed; SGEN attribution sufficientForm: Newsletter signup (footer)Implementation: Native + webhook to MailchimpRoute: submissions → Mailchimp list ID 3f8a9cAttribution: activeReason: Native captures attribution; webhook syncs to MailchimpForm: Demo bookingImplementation: Custom Codes embed (Calendly)Route: Calendly handles all routingAttribution: not in SGEN (Calendly analytics only)Reason: Scheduling requires Calendly's calendar integrationForm: Sales inquiryImplementation: Custom Codes embed (HubSpot)Route: HubSpot CRM pipelineAttribution: HubSpot UTM (not SGEN)Reason: CRM owns the sales lifecycle from submit → close

Having this document means any team member can answer "which form uses what" without digging through Custom Codes.

Related reading

• SG-Modules → Forms — native module reference
• SG-Modules → Attributions — how attribution tags submissions
• Custom CSS vs Custom Codes vs SGB Additional CSS — where the Custom Codes embed lives