User Permissions Needed
How Rep Records Arrive
The FieldKo Atlas app saves a rep’s changes on the device and uploads them when the rep syncs, manually or in the background. A rep who works a full day offline can upload dozens of visits, tasks, survey answers, orders, and ranging lines in one sync.- Records upload in batches. The app groups waiting records into upload requests by size. Batch Size For Native App in the Sync Configurations custom setting sets the size of each batch in KB (100 if blank). One batch can contain records of several objects, and records of the same object in a batch are saved together, so your flow runs once for the whole group, not once per record.
- Parents upload before children. The app saves records in upsertion order, so a visit is saved before its tasks, and an order before its order lines. A flow on a parent record that fires on create can’t see child records that haven’t arrived yet.
- Downloads come in pages. Number of Records in the same setting sets how many records each download request fetches (999 after install). See Sync.
- Each record succeeds or fails on its own. FieldKo saves each batch with partial success. If your flow causes one record to fail, the other records in the batch still save.
- Don’t put Get Records, Create Records, Update Records, or Delete Records elements inside a loop. Collect records in a collection variable, and then save the collection once after the loop.
- Prefer record-triggered flows and their entry conditions over flows that look up the same data for every record.
- Test with a realistic sync: a rep who completes a full day of visits offline, and then syncs once.
Automation FieldKo Already Runs
FieldKo includes its own flows and Apex triggers. Your automation runs alongside them in the same save, so know what’s already there before you add more.Packaged Flows
These flows come with the FieldKo packages and are active after install. To see them, from Setup, in the Quick Find box, enterFlows, and then select Flows.
The FieldKo Native package also includes Historical Location Data Populated on Attendance. It isn’t active, and you don’t need to activate it. Some older versions of packaged flows show as Obsolete. Leave them as they are.
Packaged Apex Triggers
FieldKo also has Apex triggers on its key objects, and on some standard objects. In summary, they:- Visits: Check the call cycle and required fields, keep call cycle and account visit statistics current, create calendar events, post check-ins and check-outs to Chatter, update the account’s Last Check-Out and Next Visit Plan Date, and clear missed-visit reminders.
- Tasks, task surveys, and survey answers: Keep visit task counts current, reopen a completed visit when a task is added, and clean up answers when a task is deleted.
- Accounts and users: Set a default account record type, reset geolocation flags when the shipping address changes, and share records when owners change.
- Products, price books, contracts, and ranging: Keep price book entries, product set lines, and current ranging consistent.
- FieldKo orders, call cycles, Next Visit ToDo’s, events, and files: Set order record types, share call cycles with reps, keep one active to-do per account and assignee, keep visits in step with calendar events, and link uploaded photos to their records.
Order of Execution in Brief
When a record is saved, Salesforce runs automation in a fixed order. For FieldKo records, the parts that matter most are:- Before-save record-triggered flows, including FieldKo’s flow on Visit.
- Before triggers, including FieldKo’s.
- Validation rules, and the call cycle and required-field checks FieldKo runs.
- After triggers, including FieldKo’s.
- After-save record-triggered flows, yours and FieldKo’s.
- Commit, then asynchronous work such as scheduled paths and asynchronous paths.
Choose Before-Save or After-Save
Keep a Failing Flow from Failing a Rep’s Sync
If a record-triggered flow fails and nothing handles the error, Salesforce rolls back that record’s save. For a rep, the record doesn’t reach Salesforce: the sync finishes as a partial sync, and the record shows as an issue in Sync History. You see the error on the rep’s Error Information record in Sync Details. The rep’s change stays on the device, and the same error happens again at every sync until you fix the flow or the record. To prevent this:- Add a fault path to every element that can fail, such as Get Records, Create Records, Update Records, and actions. On the fault path, log the error, for example by emailing your admin team, instead of ending the flow with an error. See Customize What Happens When a Flow Fails in Salesforce Help.
- Move notifications and emails to an asynchronous path so a failure there can’t roll back the rep’s record.
- Use entry conditions so the flow runs only for the records it’s meant for.
- Don’t add errors to records from the app on purpose. A validation-style error in a flow blocks the rep’s record at every sync. Reps can’t fix most errors from the app. See Record Types and Validation Rules.
Avoid Recursion with FieldKo Automation
FieldKo’s triggers and flows update related records. For example, when a visit is completed, FieldKo updates the account’s Last Check-Out and Next Visit Plan Date, and FieldKo’s own flows update tasks and task surveys right after the app saves them. Each of these updates runs your flows on those records again.- In entry conditions, select Only when a record is updated to meet the condition requirements, so the flow runs once when a value changes, not on every save.
- Check whether the field you care about changed, with the Is Changed operator or a formula, before you act.
- Don’t update a visit from a flow on its tasks, or an account from a flow on its visits, unless you need to. FieldKo already keeps these statistics current.
- Don’t set fields that FieldKo manages, such as visit status, call cycle, or owner.
Bypass Your Flows for Integration Users
Data loads and integrations can save thousands of FieldKo records at once. To keep them from firing rep-facing automation, such as manager alerts, give integration users a custom permission and check for it in your flows:- Create a custom permission, such as
Bypass Field Automation. See Custom Permissions in Salesforce Help. - Add the custom permission to a permission set, and assign it to your integration and data-load users.
- In each of your record-triggered flows, add an entry condition, or a first Decision element, that ends the flow when the running user has the custom permission. Use the $Permission global variable.