Skip to main content
Scoping is an important initial step while configuring your organization dashboard. It decides what Bindbee asks from a connected system. You should definitely set it before connecting real customers.

​
Configure scoping

In the dashboard, open Scoping, pick the category, and switch on the models you need. Each model expands so you can keep or drop individual fields, and Enable All turns on everything in a category at once.
The Scoping screen with HRIS, ATS and LMS tabs. Bank Info is switched off; Benefit is switched on and expanded, listing fields such as effective_date, employee_contribution, plan_name and coverage_tier, each with a Read checkbox

Each model is switched on or off and expands to keep or drop individual fields.

Scoping applies across all connectors, integrations and environments. There is no per-connector override.
A scope change takes effect on the next sync rather than immediately. Resync a connector to see the change on it - see Syncing.

​
What your customer sees

Scope is not only an internal setting. It becomes the consent screen your customer’s admin reads and approves when they authorize the connection, model by model, and each model expands to the individual fields you kept.
A consent panel reading 'Bindbee is requesting access to BambooHR - allow read access to these data models', listing Benefit, Company, Compensation, Dependent, Employee and Employment each with a green Read tick. Company is expanded to show eins, legal_name and display_name. An Allow and Continue button sits below, above a line agreeing to the End User Terms

The consent screen your customer approves. Company is expanded to the fields scoping kept.

Narrowing scope narrows what you ask them to grant, so a model or field you switch off never appears on this screen. For where the screen sits in the flow, see How to connect.

​
How to double check permission failures

Permission failures are silent. The source system leaves the data out instead of erroring, so a missing permission and an empty field look the same. One request with include_raw_data=true tells them apart. The connector’s logs carry the failing request and response - see Origin-system errors.