Salesforce orgs are usually customised: extra objects, required fields, validation rules and approval flows. The agents are designed around what you have rather than around a standard layout. We map the objects and fields they use, and we respect field-level permissions so each agent sees only the records it needs.
Larger teams often have several people who touch the same records, including sales, service and operations. The agents can be scoped by team, so a sales agent reads opportunity data and does not see service cases unless you decide it should. That scoping is agreed in the blueprint and checked again before launch.
Because changes in Salesforce can affect other teams, we move in stages and involve your administrator throughout. Because a change in Salesforce can affect other teams, we move in stages and involve your administrator from the start. The steps below show how a typical connection is staged before real records are touched.
Existing automation matters. If a flow fires when a field changes, we want to know before an agent changes it. We check for these on the discovery call and again in the blueprint, and we write down the order in which things run.
Salesforce suits larger or more complex teams, but the extra setup is a real cost. If you only need basic logging for a small team, a lighter set-up may be quicker. We will help you judge that. Every change an agent makes is logged for later review.