---
title: "Best Practices"
slug: "best-practices"
updated: 2026-10-12T15:54:27Z
published: 2026-10-12T15:54:27Z
canonical: "docs.blackthorn.io/best-practices"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blackthorn.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Best Practices

These practices come from real-world event management experience with Forge and Salesforce. Following them will save you time and reduce errors.

## Event setup

- Use the Clone feature to create a new event from an existing one — it copies ticket types, form configuration, and page settings, saving 30–60 minutes of setup per event.
- Set capacity (Maximum_Attendees__c) before activating an event. Changing capacity after registrations begin can cause waitlist edge cases.
- Create a sandbox event first if you're testing a new checkout flow, payment gateway, or form configuration. Never use a production event for testing.
- Always preview the registration page (Checkout Preview, beta) before publishing to registrants.
- Name ticket types descriptively — "General Admission — $50" is clearer than "Ticket A" when reviewing attendee reports in Salesforce.

## Attendee and registration management

- Use status filters in the Attendees tab rather than exporting and filtering in a spreadsheet. Forge queries live Salesforce data; a CSV export is a static snapshot.
- When cancelling an attendee, decide whether to also issue a refund as a separate action. Changing an attendee's status to Cancelled does not automatically trigger a refund.
- Use bulk actions (select multiple attendees, then choose an action) for status updates, email sends, and exports to avoid repetitive manual work.
- Import attendees from a CSV only when you need to manually add people who did not register through the public page — for example, comp tickets for sponsors or speakers.

## Forms and field mapping

- Map form questions to Contact or Attendee fields rather than creating new custom fields unless there is a specific reason. Reusing existing fields ensures Salesforce reports work correctly.
- Test your form end-to-end in a sandbox before attaching it to a production event. Verify that answers are correctly written to the mapped Salesforce fields.
- Use visibility rules sparingly — complex conditional logic can confuse registrants. Test every combination of conditions before launch.
- Keep forms short. Every additional required question reduces registration completion rates.

## Payments

- Test your payment gateway with a $1 charge in a sandbox before enabling paid tickets in production. Confirm the Transaction record appears correctly in Salesforce.
- Configure fees thoughtfully — passing 100% of processing fees to registrants increases sticker shock. Many organizations absorb a portion.
- Issue discount codes with expiry dates or usage limits to prevent over-redemption.
- Reconcile revenue monthly: compare Forge's Finance tab totals to your Salesforce Transaction reports and your gateway's dashboard.

## Communications

- Send a test email to yourself before scheduling any email to a real audience segment.
- Build audience segments before you need them — audience creation requires saved criteria, and building them under time pressure leads to mistakes.
- Use Salesforce's merge fields (first name, ticket type) to personalize emails. Generic emails have lower open rates.
- Schedule reminder emails at least 3 days before the event, not the morning of.

## Salesforce hygiene

- Don't delete Salesforce records that Forge created without understanding the cascading effects. Deleting an Event_Item__c that has Attendee records will cause errors.
- Run Salesforce data health reports monthly — duplicate Contacts lead to duplicate Attendee records, which distorts your registration counts.
- Review Salesforce validation rules before adding new form fields. A validation rule that blocks a field write will silently prevent form answers from saving in some configurations.