Read the task-template header
- 1
Name gives planners a recognizable reusable task bundle.
- 2
Duration is planning metadata; current route and territory optimizers do not consume it.
- 3
Description tells field users the purpose and completion standard.
- 4
Entries added after the header define the task sequence that each visit receives.
- 5
Save establishes the template before activities and checklist references are maintained.
The Visit Task Template header defines a reusable bundle before its entries and activities are added. Name is the planner-facing identity, Duration is descriptive planning metadata, and Description explains the outcome users are expected to produce. The current route and territory optimizers do not consume the Duration field, so do not present it as an enforced service-time input. The saved template can be referenced by routes, route groups, plans or individual stops, which determines how widely its work is expanded.
Use a stable name and a realistic duration measured from completed visits rather than an aspirational target. Build entries in the order a representative should execute them, mark only genuinely required activities mandatory, and verify every checklist, capture type and related-activity dependency before attaching the template to a live beat. Changes affect newly materialized work according to the generating flow; retain clear version or effective-date discipline when altering a template whose earlier form already appears on historical visits.
The work expected at each outlet is defined once, in templates, and expanded onto every visit when a plan is created. A visit task template attached to a beat or plan defines tasks and activities; a checklist template defines reusable line-by-line checks; and each activity resolves to a governed type. Mobile can use an activity's configured recordLayout; the web surface currently falls back to its generic renderer, so test both clients rather than assuming byte-for-byte behavior.
From template to visit
| Object | Role |
|---|---|
| Visit task template | The set of tasks (and their activities) expected at a stop; attached to the route or plan and expanded onto each visit at plan creation |
| Visit task | One unit of work on one visit; can be mandatory, and can be flagged as requiring a device location to start |
| Visit activity | The typed capture inside a task — its activity type decides which form opens |
| Checklist template | A reusable named checklist; scopable to a customer, a customer group, or an item, with a frequency and a mandatory flag |
Mandatory activities are marked in the mobile activity panel and gate the visit's close: a Productive outcome requires all of them done, while Non-productive and Cancelled remain available as reasoned escape hatches.
The activity catalog
Activity types are governed: the template stores the type value, and both clients resolve the same capture definition from it. The general and field-sales types are:
| Activity type | What it captures |
|---|---|
| Take Order | Full-screen catalog ordering with customer pricing; creates the order against the visit |
| Previsit | A checklist run from a checklist template |
| Digital Signature | A signature drawn on the device, attached to the activity |
| Customer KYC | Identity capture, including an OTP confirmation from the customer |
| General Task | A free start/complete task with notes |
| Survey | A configured questionnaire |
| Stock Check | Per-product counted stock at the outlet, with remarks and proof photos |
| Payment Collection | Amount, payment method with method-specific details, optional invoice allocation, proof photos |
| Return Pickup | Items returned with reasons (damaged, expired, wrong item, unsold…), against an invoice, with evidence photos |
| Merchandising Audit | Facings counted per product, planogram compliance rating, share of shelf, display observations, photos |
| Asset Verification | Condition check of company assets at the outlet, with photos |
| Competitor Capture | Competitor product, pricing, promotion and shelf-share observations, with photos |
| New Outlet Registration | A structured new-customer capture with address blocks and a storefront photo |
| Lead Capture | Opens the tenant's own lead create form |
| Product Demo | Demo execution with rating and customer feedback |
| Generate Invoice | Invoice creation from the visit |
Field-service deployments add their own set (parts consumption, meter readings, proof of delivery and more) from the same catalog.
Photos and signatures
Photo capture is part of the composed activities rather than a separate step: each type declares how many photos it expects (minimum and maximum), and the images attach to the activity as files. Signatures use a drawn signature pad and attach the same way. Both work offline — files queue with the activity and upload on sync.
Custom types
Tenants can add their own activity-type values. A type the catalog does not recognize falls back to a safe generic start/complete task — nothing breaks — and two extension renderers go further: one opens any entity's own create form as the activity, the other hosts a designer-built layout over a record the visit resolves, so a tenant can put custom capture on a visit without code.