The Core Objects at a Glance
In words: each arrow points from a parent record to the records that link to it. A rep (a user) has call cycles. Each visit links to an account, a call cycle, a sales representative, and optionally a visit template. A visit has tasks, and each task links to a task type and, for campaign work, a field campaign. A task that opens a survey has a task survey, which links to the survey and holds one task survey answer per question. A visit can also have visit notes, FieldKo orders with order line items, ranging records with ranging line items, incidents, and pack-outs. Each visit also links to the rep’s attendance record for that day.Visits, Tasks, and Surveys
A visit’s sales representative decides which rep gets the visit in the app, and FieldKo sets the visit’s owner to that rep. See Visit Rules Enforced by Salesforce.
Planning Objects
Orders and Ranging
Products, price books, contracts, and product sets decide what reps can order and range. For how they connect to accounts, see How the Objects Relate.
FieldKo Native Objects
The FieldKo Native package adds these objects, which the FieldKo Atlas app fills in:
FieldKo Native also has Object Metadata and Profile Metadata objects, which hold what the Metadata Collector stores for the app. Don’t edit or report on them.
Why Relationship Types Matter
- Sharing: A child in a master-detail relationship, such as a task survey, visit note, or order line item, has no sharing of its own. Users who can see the parent can see the child. Lookup children, such as tasks and task survey answers, follow their own org-wide default. See Security Model and Sharing.
- Deletion: Deleting a master record deletes its detail records. Deleting a visit deletes its visit notes, and deleting a task deletes its task surveys.
- Reporting: A report type can follow relationships from parent to child. To report across objects that FieldKo’s report types don’t join, create a custom report type. See Report Folders, Sharing, and Custom Report Types.