FieldKo operates entirely within your Salesforce org, which means it inherits Salesforce’s robust security and sharing model. Properly configuring Org-Wide Defaults (OWD), roles, and sharing rules for FieldKo objects is crucial to ensure that field data is visible only to the right people. This article explains how to set up record access security for FieldKo.
Salesforce Security Model Overview
Salesforce security works in layers: object-level access (profiles/permission sets), and record-level access (Org-Wide Defaults and sharing). By now, you’ve given users object access via FieldKo permission sets. Now we address record visibility.
Org-Wide Defaults (OWD): Org-Wide Default settings specify the baseline level of access to records for each object across the whole org. In simpler terms, OWD defines what the most restricted user can see. You generally set an object’s OWD to the most restrictive level and then open up access with role hierarchy or sharing rules as needed.
Role Hierarchy: Roles let you reflect your organisation’s org chart in Salesforce. Users higher up in the hierarchy automatically gain access to records owned by those below them (if “Grant Access Using Hierarchies” is enabled). This is ideal for FieldKo: a field manager role above field reps means the manager can see the reps’ visit records without extra sharing rules.
Sharing Rules: These are rules you define to open access between peers or to groups that aren’t in the same hierarchy. For FieldKo, you might use sharing rules if, say, certain project coordinators need access to all visits in a region even if they aren’t the manager, or to share data with corporate users who are not in the field roles.
Important principle: OWD can only restrict access, not grant more than a user’s profile permits. A user must have object permission first (via profile/perm set), then record access via OWD/role/sharing.
Given FieldKo’s use case, you’ll likely want a Private or limited sharing model for field data to protect it, and then selectively allow managers or others to see it.
Setting Org-Wide Defaults for FieldKo Objects
After installing FieldKo, identify the custom objects it introduced (e.g., Visit, Visit Task, Survey Response, Attendance Log, etc. – actual names may vary). For each of these objects, decide on the default internal access:
Visit (or equivalent) – These are the records of store visits done by field reps. Likely set this to Private. That means only the record owner (the field rep assigned to the visit) and their managers (role hierarchy) can see it. This prevents reps from seeing each other’s visits. Managers will see them through hierarchy if enabled.
Task/Activity (if FieldKo uses standard Task records) – If FieldKo is configured to use standard Salesforce Tasks for some actions, note that Tasks have their own OWD setting (share via parent or controlled by owner). Typically, tasks are controlled by whoever can see the parent record or the owner. Ensure it aligns with Visit (e.g., if tasks are child of a Visit, access follows the Visit).
Survey or Questionnaire Objects – If survey responses are stored in a separate object, also set those to Private, and likely mark them as controlled by parent (if the parent is Visit) so that anyone who can see the Visit can see related survey answers.
Account (Stores) – Accounts might already exist in your org for stores. Decide if all FieldKo users can see all account records, or not. Often, Accounts for retail stores are set to Public Read-Only (so everyone can at least view basic info), because hiding store info serves little purpose and reps may service multiple stores. If your reps are territorial and shouldn’t even know about other stores, you could set Account to Private too, but then you must assign accounts to users/teams via sharing rules or territories. A middle ground is Public Read-Only for Accounts (so any rep can see store addresses, etc., which is often fine) and Private for child objects like visits.
Contact (Store contacts) – Likely similar to Account; could be Public Read-Only if you don’t mind all reps seeing contact names (like store managers’ names), or Private if needed.
Attendance Logs – If FieldKo has an Attendance object capturing user check-in/out times, you might set that to Private as well, so that one field rep cannot see another’s time logs. Managers could see their team’s if hierarchy is allowed. Possibly, you might even restrict managers if attendance is only reviewed by HR or admins – in that case, keep hierarchy off for this object and use a sharing rule to let a specific profile (HR) see all.
Any other objects (Photos, Mileage, etc.): Consider each. Photos might be attachments or a custom object related to Visit; if related to Visit, control via parent (so follow Visit’s access). Mileage logs might be individual to each user – Private is sensible, with maybe managers allowed via hierarchy to check their team’s mileage if relevant.
To set Org-Wide Defaults:
Go to Setup > Sharing Settings (Quick Find “Sharing Settings”).
Click Edit in the Organization-Wide Defaults section.
For each FieldKo object, choose the default access level. For custom objects, your choices are Private, Public Read Only, or Public Read/Write (and Controlled by Parent if it has a master-detail parent). Select Private for objects like Visit, Task, Survey, etc., to keep data restricted.
Ensure Grant Access Using Hierarchies is checked for these objects (the checkbox appears for custom objects when you set to private or read-only). This allows role hierarchy to apply. (For standard objects like Account, hierarchy is always on by default except some special ones like Cases where it’s optional).
Save the OWD settings. Salesforce will recalculate access which might take a moment if there’s lots of data (in a new FieldKo install with few records, it’ll be quick).
Now, with OWD set, by default each user only sees their own records on those objects.
Role Hierarchy Configuration
Design a role hierarchy that mirrors your field team structure, if not already in place:
Example Hierarchy:
Field Operations Manager (top of field team, perhaps one per region)
Area Supervisor (if any mid-layer)
Field Sales Rep / Merchandiser (bottom level, owning the visit records)
Place each user in the appropriate role. With hierarchy access, a manager in the “Field Operations Manager” role will automatically see records owned by users in the roles beneath them (their team). This means a manager can run reports or view all visits done by their direct and indirect reports without additional sharing rules.
If your org already has a role hierarchy for sales, you can reuse it or add a branch for FieldKo if needed. For instance, if FieldKo is used by a subset of users, you might create a parallel branch like “Field Team” separate from “Corporate Sales” roles.
Make sure that Grant Access Using Hierarchies is enabled for the FieldKo objects (it is by default for most, but custom objects give you the option to disable it – do not disable it unless you have a very specific reason). Keeping it on greatly simplifies access control.
Sharing Rules for Additional Access
Consider if anyone outside the direct hierarchy needs access to FieldKo records:
Cross-Team Visibility: Maybe you want all field reps to see each other’s visits (perhaps to learn from them or avoid duplicate store visits). This is not common (usually reps focus on their assignments), but if needed, you could create a sharing rule on Visit object: share from role “Field Rep” to all users in role “Field Rep” as read-only. That would make visits visible to peers. Use with caution since it exposes data broadly.
Regional Manager or Analyst: Perhaps a regional executive or an analyst (not in the field hierarchy) needs to see all FieldKo data for reporting. The simplest way is to create a public group (e.g., “FieldKo Reporting Users”) and a sharing rule: share all Visit records with that group as Read Only or Read/Write. This bypasses role hierarchy. Alternatively, place those users temporarily in a high-level field role just for access.
Portal/External Access: If external partners are using FieldKo via Experience Cloud (portal users), sharing is handled via either the account relationship or custom sharing sets. Typically, for external users, you might set the OWD for Visit to Private, and then use a sharing set that says “Portal user can see Visit records if Visit.Account = user’s Account” (meaning they can see visits for the store they’re associated with). Configure sharing sets in Setup > Communities > Sharing Settings for the community profile. This ensures third-party merchandisers only see their own store visits.
Manager Visibility for Specific Objects: If you turned off hierarchy for something like Attendance logs but you do want managers to see them, you’d need a sharing rule: e.g., share Attendance records with Role = Manager role, perhaps criteria-based (owner’s role = Field Rep, share with that user’s manager). Sometimes it’s easier to leave hierarchy on, but if not, then define criteria-based sharing such as “Attendance where User field’s Manager = X share with X”. This might need an Apex sharing or manual approach if standard sharing can’t do it easily.
When creating sharing rules, identify the object, define the record criteria (or all records), and the target users (roles, roles and subordinates, public groups) and level of access. For FieldKo, default read-only access is usually sufficient for anyone who isn’t the owner or admin.
After setting sharing rules, click Recalculate if prompted to apply them. Document any special sharing for your org’s governance.
Field-Level Security and Data Sensitivity
Beyond record access, review FieldKo’s fields for any sensitive data:
Personal Data: If FieldKo stores personal data (maybe pictures of individuals, or notes that include personal info), ensure compliance with privacy standards. For example, if a survey allows free text, users might enter something sensitive – you may want to restrict who can see that field.
Field Permissions: In Profiles or Permission Sets, adjust field-level security for such fields. For instance, maybe only admins can see “Visit Notes” field if it could contain sensitive info, whereas field reps and managers can’t after submission. However, by default, FieldKo permission sets likely give broad access to all necessary fields for functionality. Only tighten if needed.
Encryption: If you have Shield Platform Encryption and need to encrypt certain FieldKo fields (like location coordinates, etc.), coordinate with FieldKo support – ensure encryption won’t break any functionality that uses those fields (some searches or calculations might be impacted by encryption).
Testing Security Settings
Finally, test the security model thoroughly:
Field Rep Perspective: Log in as a field rep user. Verify they can:
See the FieldKo app and their own visits/tasks.
Not see other reps’ visits. For example, use global search to try finding a Visit record owned by another user – it should not appear.
Not access any admin-only tabs or data. If you have a separate Attendance object and you chose not to expose it, ensure the rep can’t see those records.
Manager Perspective: Log in as a manager (role above reps):
They should see their own visits plus those of their subordinates. In the FieldKo app, maybe a manager has a view or report listing team visits; ensure it’s populated.
They should not see visits of teams outside their hierarchy. If you have multiple regions, one region’s manager shouldn’t see another’s data.
Other roles: If you set up an exec or analyst with a special sharing rule, verify that access.
External User: If applicable, log in via the community as a partner user. They should see only what they’re meant to (e.g., visits for their store). Ensure they cannot hack the URL to see other records – Salesforce’s sharing model will prevent access if configured correctly.
Note: A quick way to simulate what someone can see is using the “View All as” feature in the Role Hierarchy setup for territories or the manual sharing button (though those are limited). More practically, create a dummy user in each role, assign FieldKo permission sets, and use Login As to check. Keep these test users active until you’ve verified everything.
By configuring Org-Wide Defaults to Private for FieldKo data and leveraging role hierarchy and sharing rules, you achieve a principle of least privilege: field reps see only their work, managers see their team’s work, and higher-level or other stakeholders see only what they need. This protects sensitive field information (like store visit results or images) from being visible to unauthorised users, which is especially important when you have a large field force or external partners.
In summary, Salesforce’s built-in security combined with FieldKo’s architecture provides a secure environment out-of-the-box. With a proper setup as described, you can be confident that your FieldKo deployment data is partitioned and accessible in accordance with your organisation’s policies. Now that security is set, let’s turn to the Data Sync and Offline capabilities to ensure your field users have a seamless experience on the go.