> ## Documentation Index > Fetch the complete documentation index at: https://support.fieldko.com/llms.txt > Use this file to discover all available pages before exploring further. # Security Model and Sharing > Understand how Salesforce sharing and FieldKo's sync rules work together, and choose org-wide defaults for FieldKo objects. 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 | To do this | You need | | - | - | | Change org-wide defaults and sharing rules | Manage Sharing | | Set up account teams | Customize Application | ## Salesforce Sharing Building Blocks | Tool | What It Does | FieldKo Notes | | - | - | - | | Org-wide defaults | The baseline access for each object: Private, Public Read Only, or Public Read/Write | See [Recommended Starting Org-Wide Defaults](#recommended-starting-org-wide-defaults) | | Role hierarchy | Opens records up to users above the owner | How managers usually see their reps' visits. See [Roles and the Role Hierarchy](/platform/access/roles). | | Sharing rules | Share records by owner or criteria with groups and roles | Required for accounts in public group mode | | Account teams | Add users to an account with a set access level | FieldKo syncs an account to every rep on its account team, and field campaigns can assign visits to account team members | | Manual sharing | Share one record with one user or group | Lets a user see the record in Salesforce, but doesn't make it sync to a rep | 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](https://help.salesforce.com/s/articleView?id=sf.security_data_access.htm\&type=5) in Salesforce Help and the [Data Security](https://trailhead.salesforce.com/content/learn/modules/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](/admin/offline-data). 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. ## Recommended Starting Org-Wide Defaults 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. | Objects | Recommended Default | Why | | - | - | - | | **Account** | Private, or Public Read Only | FieldKo syncs accounts by ownership and account team either way. Choose Private if reps shouldn't browse other reps' stores in Salesforce. | | **Contact** | Controlled by Parent | Contacts follow their account | | **Visit** | Private | FieldKo sets each visit's owner to its sales representative, so reps see their own visits and managers see their teams' visits through the role hierarchy | | **Task**, **Next Visit ToDo's** | Public Read/Write | These can be owned by the person who created them, such as a manager who planned the visit, and reps need to update them | | **Call Cycle** | Public Read Only | Admins and the scheduled job often create call cycles for reps, and a rep must be able to see their own call cycle to get any visits | | **FieldKo Order**, **Ranging** | Private, or Public Read Only | Reps create these. Choose Public Read Only if reps should see other reps' order and ranging history for the same stores. | | Setup data: **Task Type**, **Survey**, **Question**, **Visit Template**, **FieldKo Product**, **FieldKo Pricebook**, **Product Set** | Public Read/Write | Reps' permission set grants only read access to these objects, so they can't edit them anyway. Public Read/Write lets every manager maintain them. | | **Attendance**, **Incident**, **Pack Out** | Private | Reps create their own records, and managers see them through the role hierarchy | | **Sync Detail** | Private | Sync logs can contain record data. See [Restrict Sync Detail Visibility](#restrict-sync-detail-visibility). | 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](/platform/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](/admin/support-diagnostics#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](/admin/support-diagnostics#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](/admin/installation#remove-a-reps-access). * For large reorganizations, ask your Salesforce account executive or Salesforce Support whether deferring sharing calculations is available for your org. ## See Also * [Roles and the Role Hierarchy](/platform/access/roles) * [Control What Syncs to the App](/admin/offline-data) * [Diagnose Rep Issues](/admin/support-diagnostics) * [Plan for Data Volume, Storage, and Retention](/platform/data/data-volume) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.