Task · Workflows

Send attendees to Salesforce

Create or update a Salesforce contact as tickets are bought and changed.

6 steps · About 8 minutes

Salesforce holds the people your organization already knows about. This keeps it up to date as tickets are bought and changed, so an attendee is a contact before anyone goes looking for them.

You'll need a Salesforce login that can create contacts, and the API name of the field you want Tito to match on. That field is what tells Salesforce an update from a new person, so it has to be marked as an external ID.

1. Add an external ID field in Salesforce

   In Salesforce, open Setup, then Object Manager, then Contact, then Fields & Relationships. Create a text field, tick External ID and Unique, and note its API name. It usually ends in __c.

   You can use Email instead if every contact in your org has one and no two share it.

   Email is a standard external ID on Contact, so there's nothing to create. Tito matches on whatever you name in the address, so pick the one your org already trusts.

2. Connect Salesforce

   Open Integrations in account settings. Salesforce is under Other services, below the payment providers. Select Connect and sign in. Salesforce asks you to allow access, and sends you back here.

   Tito connects to the org you're signed in to at that moment.

   If you keep more than one org open, sign out of the others first, or connect from a private window.

3. Start from the template

   Open Workflows, select New from template and choose Send attendees to Salesforce.

   Your accountWorkflows

   go.tito.io/acme/admin/workflows

   That creates an ordinary workflow you can edit, already set up to fire when a ticket is bought or changed. It arrives switched off.

4. Put your field's API name in the address

   Open the workflow and look at what it sends. The address ends /sobjects/Contact/YOUR-EXTERNAL-ID-FIELD/.

   Replace YOUR-EXTERNAL-ID-FIELD with the API name from the first step, so it reads /sobjects/Contact/Email/ or /sobjects/Contact/Tito_Ticket__c/.

   Replace that text before you can turn the workflow on.

   The switch stays out of reach and says so, because a workflow left with the example text in it would send every ticket to an address Salesforce doesn't have, and the run log would be the only place it showed.

5. Check what's being sent

   The template sends a starting set: the attendee's first and last name, their email, and the event name in a description. Every line is a Salesforce field API name on the left and what Tito puts in it on the right.

   Salesforce refuses the whole record if it's sent a field name that doesn't exist on Contact, so change a name here only to one you know is there. Adding a line for a field you added yourself works the same way.

6. Turn it on

   Switch the workflow on. It starts with the next ticket.

   To bring across the tickets sold before you turned it on, see Catch up a workflow on tickets already sold.

Good to know

Tito matches on the field you named, so running the same ticket through twice updates the contact instead of making a second one.

A contact Tito updates keeps everything Salesforce already had on it. Only the fields in the workflow are written.

Your Salesforce org has a daily limit on API calls shared by everything that talks to it. A busy on-sale spends from the same allowance as your other tools.

If a run fails, the run log has Salesforce's own reply in it, which names the field it objected to.

Salesforce ends the connection if nothing uses it for 30 days. After a gap of 30 days between events, reconnect on the Integrations page before your next on-sale. Runs that happen after it lapses fail and say so.