Not every Salesforce field needs Quin writing to it

A Salesforce org built up over several years accumulates fields nobody quite remembers the purpose of, alongside the ones that matter every single day. Given access to all of them at once, an integration doesn't know the difference any better than a new hire would on their first day.

What comes with giving broad access by default

• Notes landing on fields nobody reads regularly, while the fields people check daily go untouched.
• Custom fields specific to one team's process getting updated by a workflow that wasn't built with them in mind.
• Sensitive or restricted fields being touched by an integration that didn't need access to them in the first place.
• A cleanup project down the road, once someone notices the data doesn't look the way it should.
• A harder conversation about trust, once one mistaken update makes the whole integration feel less reliable than it is.

How Quin handles it

Salesforce's integration settings let you choose which objects and fields Quin can read or write to, rather than granting blanket access. Quin selects commonly used ones by default, but every object and field can be added or removed, and the selection can change at any time as your needs do. A large org with dozens of custom objects doesn't need to expose all of them just to get value from the ones that matter most.

Say your team uses a custom field to track a specific compliance step that shouldn't be touched by an outside integration. Leaving that field out of Quin's selection means it stays exactly as your team manages it, while the fields you do want updated still get the same treatment as anything else.

Why this matters

An integration with access to everything isn't necessarily more useful. It's just more likely to eventually touch something it shouldn't have. Choosing the specific objects and fields Quin works with is what keeps broad CRM access from turning into a trust problem down the line, especially in an org where different teams rely on different parts of the same records.

Getting the most out of it

• Start from the default selection and adjust from there, rather than opening every object at once.
• Review the field list periodically as your Salesforce org changes, since new custom fields won't be selected on their own.
• Coordinate with whoever manages your Salesforce org before making changes that affect shared fields.
• Use Guidelines alongside field selection for finer control over what gets written where.

Setting it up

Connect Salesforce under Settings, then Integrations, and click into the Salesforce integration to review the objects and fields Quin can access. Adjust the selection to match what your team needs, and save the changes to apply them.