Salesforce Data Model Basics for Form Builders: Objects, Lookups, and Record Types

A form builder who does not work in Salesforce every day can build reliable forms with a short list of concepts. Salesforce stores data in objects, which act like tables, and each object holds fields, which act like columns. Standard objects such as Contact, Account, and Lead ship with Salesforce, and administrators add custom objects for their own needs. Every field a form maps to must exist on an object, and every value must match what that field accepts.

Objects and Fields

An object is a type of record, such as a Contact or a Case. A field is one piece of data on that record. Fields have types, such as text, number, date, checkbox, and picklist. A picklist field offers a fixed list of values, and a restricted picklist rejects any value outside the list. A form that sends “Web Form” to a restricted picklist that expects “Web” fails, so the choices in the form must match the Salesforce values.

Lookups and Relationships

Objects connect through relationship fields. A lookup relationship links a child record to a parent record without tying their lifecycles together. A master-detail relationship ties the child to the parent, so the child cannot exist without it. Salesforce’s documentation on object relationships explains both. For a form, relationships decide order: the parent record must exist before the child can point to it. FormAssembly handles this by linking records inside the connector, where a child step uses the ID of the record that an earlier step created.

Record Types

Record types let one object serve several purposes. According to the Salesforce metadata reference, record types offer different business processes, picklist values, and page layouts to different users. A Contact record type for donors and another for volunteers can show different picklist values, so a form that targets a record type must send values that belong to that type.

Fields a Form Cannot Write

Some fields are read-only. FormAssembly’s help center notes that, because of how the Salesforce API works, FormAssembly in general cannot access auto-number, formula, and lookup field types. A form can read such values after Salesforce calculates them, so teams should plan to use them in follow-up steps instead of mapping them from the form.

Where FormAssembly Fits

FormAssembly’s Salesforce connector sends data to any standard or custom object that the Salesforce API exposes, and it can create, update, and look up records. A “See all Salesforce Objects” option in the connector shows how FormAssembly sees the org’s objects and fields, which helps non-admins confirm what each field accepts. Conditional logic and field validation keep values inside what the org allows, and forms connect directly to Salesforce, so errors surface during testing instead of in production.

Business analysts who learn these four concepts – objects, picklists, relationships, and record types – can plan a form with the Salesforce admin in one short conversation.