Collection Routine use cases
This page gathers complete configuration examples of Collection Routines for common everyday scenarios. Each example follows the same structure: the scenario, the recommended configuration (routine and tasks) and what happens in practice — both during the collection window and when it closes. This way, you can identify the case closest to your needs and adapt the configuration.
Before reproducing the examples, it is important that you already know:
- How to create a form — tasks only accept published forms;
- How to create a Routine — name, collaborators and start date;
- How Tasks and Periodicities work — form, window, number of collections and counting options.
The routine and form names used in the examples ("Store opening", "Opening checklist", etc.) are fictional. Use the names that make sense for your operation.
1. Daily store opening checklist
Scenario: the store must fill out an opening checklist every day, before starting to serve customers. It doesn't matter who fills it out — it's enough that one of the people in charge on site records the opening.
Recommended configuration:
- Routine "Store opening", with everyone responsible for opening as collaborators;
- Task with the "Opening checklist" form (published), with:
- Periodicity: Daily;
- Number of collections: 1;
- "All collaborators must send": off — anyone in charge who is present can record the opening;
- "Accept extra collections": off — only one opening per day makes sense.
What happens in practice:
- Every day, a new "To Do" activity appears in My Activities for the routine's collaborators;
- The first collection of the day completes the activity for the whole group;
- A second submission on the same day is rejected, since the window's limit has already been reached and extra collections are turned off;
- If the day ends without any collection, the system automatically records a not executed activity, visible in Monitoring.
2. Weekly safety inspection
Scenario: each safety technician needs to perform their own inspection once a week. Here it's not enough for someone in the group to send: the requirement is individual.
Recommended configuration:
- Routine "Safety inspections", with all technicians as collaborators;
- Task with the "Safety inspection" form (published), with:
- Periodicity: Weekly;
- Number of collections: 1;
- "All collaborators must send": on — counting is no longer per group and becomes individual: each technician must send their own collection during the week.
What happens in practice:
- Each technician sees their own pending item for the week in My Activities; a colleague's submission does not complete the others' activity;
- At the end of the week, the system records a not executed activity for each technician who did not send — in Monitoring you can see exactly who fell behind, since each record is associated with the corresponding collaborator.
The weekly window follows the start day of the week configured in the workspace and the time zone of the workspace owner — not the settings of each collaborator's device.
3. Fortnightly sales report
Scenario: the sales team consolidates a sales report twice a month. Any team member can send the consolidated report.
Recommended configuration:
- Routine "Sales reports", with the sales team members;
- Task with the "Sales report" form (published), with:
- Periodicity: Fortnightly;
- Number of collections: 1;
- "All collaborators must send": off — counting is global: a submission from any member completes the fortnight.
What happens in practice:
- The windows follow fixed calendar dates: from day 1 to 15 and from day 16 to the end of the month;
- Any member can send the report within the fortnight;
- When each fortnight closes, if no one has sent, the system records the pending item as a not executed activity in Monitoring.
The Fortnightly periodicity uses calendar dates (1 to 15 and 16 to the end of the month), and not rolling 14-day cycles. This means the second window of the month may have 13, 14, 15 or even 16 days, depending on the month — but the closing always happens at the same points in the calendar, which makes management follow-up easier.
4. Weekday security patrol
Scenario: the security team performs patrols only from Monday to Friday, three times a day. Additional patrols are welcome and should not be blocked.
Recommended configuration:
- Routine "Patrols", with the security guards as collaborators;
- Task with the "Patrol log" form (published), with:
- Periodicity: Weekdays, with Monday to Friday selected;
- Number of collections: 3;
- "All collaborators must send": off — the day's 3 patrols are a group goal;
- "Accept extra collections": on — patrols beyond the 3 expected are accepted normally.
What happens in practice:
- Saturdays and Sundays do not generate activities, and submissions made on those days are rejected, since they are outside the task's allowed days;
- On each weekday, 3 collections are expected; thanks to extra collections being on, submissions beyond the 3 are also accepted and recorded;
- If a weekday ends with fewer than 3 collections, the system automatically records the missing not executed records (for example: 1 patrol done → 2 not executed activity records).
In the Weekdays periodicity, the manager chooses the allowed days of the week. You could, for example, select only Monday, Wednesday and Friday — the other days would not generate activities and would not accept submissions for that task.
5. Monthly meter reading in the field (offline)
Scenario: meter readers visit facilities in remote areas, with no internet access, and each one needs to record the readings once a month.
Recommended configuration:
- Routine "Monthly readings", with the meter readers as collaborators;
- Task with the "Meter reading" form (published), with:
- Periodicity: Monthly;
- Number of collections: 1;
- "All collaborators must send": on — each meter reader is responsible for their own reading of the month.
What happens in practice:
- The month's pending item is available in the My Activities tab of the mobile app even without a connection;
- A collection made offline already clears the pending item on the device itself — the meter reader sees the activity as completed, with an indication that the submission is pending;
- The collection officially counts toward the window when the device syncs with the server.
Learn more about how My Activities works offline.
Instruct the team to connect the device and sync before the monthly window closes. If the window closes before the collections have reached the server, the system will record the activity as not executed for the collaborator — a collection made offline only counts officially after syncing.
Comparative summary
The table below summarizes the five cases so you can choose the model closest to your scenario:
| Case | Periodicity | No. of collections | All must send | Extra collections | Main effect |
|---|---|---|---|---|---|
| Store opening checklist | Daily | 1 | Off | Off | One collection per day, made by anyone in charge; submissions beyond the limit are rejected |
| Weekly safety inspection | Weekly | 1 | On | Off | Each collaborator has their own weekly pending item; Monitoring shows who did not send |
| Fortnightly sales report | Fortnightly | 1 | Off | Off | Fixed calendar windows (1–15 and 16–end of month); one submission from the group completes the fortnight |
| Weekday patrol | Weekdays (Mon–Fri) | 3 | Off | On | No activities on weekends; 3 collections expected per weekday and additional submissions accepted |
| Monthly offline reading | Monthly | 1 | On | Off | Individual pending item available offline in the app; the collection counts upon syncing |
A routine can have several tasks, each with its own form and periodicity. If the same group of collaborators has, for example, a daily checklist and a weekly inspection, you can keep both tasks in the same routine, simplifying management. See more in Tasks and Periodicities.