Skip to main content
Salesforce sharing decides which records each user can see and edit, in Salesforce and in the FieldKo Atlas app. FieldKo adds its own rules on top that decide which of those records sync to each rep’s device. This page explains how the two layers work together, recommends starting org-wide defaults for FieldKo objects, and covers what to watch for with sync logs and large sharing changes.

User Permissions Needed

Salesforce Sharing Building Blocks

FieldKo also creates some sharing records itself. For example, when an account gets a new owner, FieldKo shares the account’s current ranging and, if you turn it on, last month’s orders with the new owner. For an introduction to sharing, see Control Who Sees What in Salesforce Help and the Data Security module on Trailhead.

What Syncs vs. What Users See

Keep these 2 rules in mind when you design sharing for FieldKo:
  1. What users see follows Salesforce sharing. Sync runs as the rep and respects sharing and field-level security. A record a rep can’t see never reaches their device, and an edit a rep isn’t allowed to make fails when they sync.
  2. What a rep syncs follows FieldKo’s rules. Of the records a rep can see, FieldKo syncs the accounts they own or are on the account team for, the visits where they’re the Sales Representative, and the related tasks, survey answers, orders, and ranging within a date window. See Control What Syncs to the App.
So adding sharing doesn’t add FieldKo records to a rep’s device, but removing sharing can remove them. The exception is objects FieldKo has no rule for, such as your own objects without a lookup to Account or Visit. The app syncs every record of those objects that the rep can see, so for them, sharing decides what syncs. These are recommendations, not requirements. They’re a starting point for a typical field team where reps work their own stores and managers see their teams through the role hierarchy. Detail objects, such as Task Survey, Visit Note, and FieldKo Order Line Item, are controlled by their parent and have no default of their own. See FieldKo Data Model.
Records a rep can’t see don’t sync, and no error appears. Before you make any FieldKo object more restrictive in production, test it in a sandbox: plan a visit as a manager, sync as a rep, complete the tasks, surveys, and an order, and sync again. Then check the rep’s Sync Details for errors.

Restrict Sync Detail Visibility

Data 1 and Data 2 on Sync Detail records can contain record data from reps’ devices, and all internal users can read the Sync Detail object by default. Set its org-wide default to Private, and give the admins and support staff who troubleshoot sync the access they need through the role hierarchy or a sharing rule. See Sync Details.

Plan for Sharing Recalculation

Changing an org-wide default, editing the role hierarchy, moving users between roles, or changing the owner of many accounts makes Salesforce recalculate sharing. In orgs with many visits, tasks, and survey answers, this can take a long time. While it runs, some sharing changes can’t be made.
  • Make these changes outside working hours, and avoid times when reps are syncing heavily, such as the start of the day.
  • Change account ownership in batches. Each owner change also makes FieldKo move or share related data, such as future Not Started visits, depending on Transfer Data On Change Of Account Owner. See Remove a Rep’s Access.
  • For large reorganizations, ask your Salesforce account executive or Salesforce Support whether deferring sharing calculations is available for your org.

See Also

Last modified on October 20, 2026