The Complete Guide to Task Management Forms

An Introduction to Forms: Concepts, Terminology, and Behavior

This article is your starting point for understanding how Forms work in Task Management. It explains what the feature is, who it’s for, the concepts and terminology you’ll encounter throughout the product, and the behavior rules that govern how forms are created, distributed, filled out, and reported on. Read this once before diving into the step-by-step how-to articles — most things will make a lot more sense afterward.

1. What Forms Are and Who Uses Them

A Form is a structured set of questions that field employees fill out during a channel visit. You build a form once in the Client Portal, assign it to specific channels (and optionally to specific working groups), and it then appears in the field employee’s mobile app whenever they check in to a relevant channel.

There are two main audiences:

• Client Portal admins — design and manage form templates, configure who receives them, and review the submitted data through exports.
• Field employees — receive assigned forms during their visits, fill them out on mobile, save drafts, and submit them as part of the channel check-out flow.

A typical use case: a beverage distributor wants every sales representative to record stock levels and shelf placement at every outlet they visit. The admin creates a “Daily Stock Check” form template, assigns it to the relevant outlet channels, and reps see the form in their visit checklist whenever they check in.

2. Key Terminology

Throughout the product (and these help articles) you’ll see these terms. Here’s what they mean:

• Form Template — the form definition you create and manage in the Client Portal. It has a name, a structure (pages and questions), and configuration (training material, target, availability, assignment).
• Form Assignment — the configuration that controls who sees a form: which channels, and within those channels, which employees (all employees vs. a specific working group).
• Daftar Tugas — the “Tasks” section on mobile that lists forms the employee is eligible to fill during the current visit.
• Aktivitas — the “Activity” section on mobile that lists the forms the employee has saved as drafts during the current visit.
• Snapshot — the locked-in configuration captured when an employee successfully checks in. Once snapshotted, mid-visit changes by an admin do not affect the current visit.
• Draft — a form an employee has saved on mobile but not yet submitted. Drafts count toward the target counter and can be edited.
• Submission — a finalized record. Drafts become submissions when the employee completes check-out from the visit.
• Form ID — the unique, immutable identifier generated when you first create a form template. It never changes (format: ClientID-MMYYYY-10character).
• Version — an incremental number that increases only when you save changes that affect the form’s structure (Step 2 Form Builder or Step 3 Logic Jump).
• Compound Input Type — a reusable, item-based question group that operates on a database (e.g., one block of questions repeated per SKU). Covered briefly in Section 12.

3. The Five-Step Form Creation Lifecycle

Creating a form template walks you through five steps in order. You can navigate freely between them within a session, but they have distinct purposes:

The Save buttons on these steps follow scope rules — see Section 8.

4. Input Type Categories

A form can use 25+ input types, organized into a few categories that behave differently downstream:

• General Input Types capture qualitative or descriptive data: text, number, date, dropdown, checkbox, radio, photo, file upload, email, phone. They’re stored per submission and surfaced in raw exports.
• Attribute Input Types capture structured, measurable data designed for aggregation across submissions: standard price, MSRP, consumer price, total sales, stock, shelf length, and more. They’re report-ready by design and feed into dashboards and analytics.
• Sub-field Packages are bundles of two or more inputs that behave as a single, indivisible unit — for example, Stock OPEN-ENDING (which captures both the opening and ending stock as one logical input) or Photo Before-After (which captures two image sets in one question). You cannot split or remove the sub-fields individually.
• Compound Input Types are reusable item-based question groups (covered in Section 12).
• Shelf Share is a specialized compound type with auto-calculated total length and per-item percentage. It’s exclusive to Compound and cannot share a compound with any other input type.

When choosing an input type, consider the downstream use: if you want to aggregate or compare values across submissions in dashboards, pick an Attribute type. If you only need to capture a value for the record, a General type is fine.

5. Form Visibility on Mobile

A form does not appear automatically — visibility is gated and time-bound:

• Check-in is required. Forms are hidden until the employee successfully checks in to a channel. Only after check-in do assigned forms surface in Daftar Tugas.
• Channel + (optional) working group must match. Forms are filtered by the form assignment configuration. If the form is assigned to specific channels, the employee must be visiting one of them. If working group filtering is applied, the employee must also belong to the configured WG → Level → Node combination.
• Temporary forms have a date window. If you mark a form as Temporary, it only appears within its Active Period. Outside that window, it’s invisible — even to employees who would otherwise be eligible.
• Targets affect interactivity. When a form has a target, the form card shows a counter (0/2 grey, 1/2 orange, 2/2 green). Once the target is reached, the form becomes disabled in that visit and cannot be opened to create new drafts.

6. Targets and Achievement

A target tells the system how many submissions an employee must complete for a given form. There are three target modes in the configuration UI, but only one is currently enforced:

A few key behaviors of the achievement counter:

• Drafts increment the counter. Saving a draft (tapping Simpan) immediately increases the counter by 1.
• Editing a draft does not. If you reopen and re-save an existing draft, the counter stays the same.
• Final submission does not double-count. Submitting drafts via Kirim + Check-out doesn’t add to the counter again — drafts already counted.
• Reaching the target blocks new drafts. Once the counter shows Q/Q (green), the form is disabled and cannot be opened in that visit.
• Per Visit gates the Summary. If a Per Visit target isn’t met, the employee can’t proceed from Detail Kunjungan to the Ringkasan (Summary) page until they complete the missing submissions.

7. Form Versioning and Form ID

This is one of the most important behaviors to understand if you ever modify a form after publishing.

The Form ID is permanent. It’s generated once at creation in the format ClientID-MMYYYY-10character (e.g., 1234-022026-Uhd8adgr12) and never changes — not when you rename the form, not when you edit the structure, not ever. The Form ID is the stable reference used in submissions and exports.

The Version increments only on structural changes. Specifically:

• Changes to Step 2 (Form Builder) — adding/removing/editing pages, questions, input types, options, training material — bump the version.
• Changes to Step 3 (Logic Jump) — adjusting jump rules — also bump the version.
• Changes to Step 1, Step 4, or Step 5 — name, description, target, availability, assignment — do not bump the version.

Reverting before saving doesn’t create a version. If you change a question title from “X” to “Y” and then change it back to “X” before saving, no new version is created.

One save = at most one version increment. If you make ten structural changes and save once, the version goes up by one.

Question IDs are preserved across edits. Modifying a question’s title, options, mandatory flag, or input type keeps the same Question ID. Only adding a brand-new question (manually or via duplicate) generates a new Question ID.

8. Save Scope When Editing an Existing Form

When you edit a form, the Save button does different things depending on which step you’re on. This is non-obvious and worth committing to memory:

Why this matters. If you’re making a quick name change in Step 1 only, save in Step 1. But if you’ve also been editing the form structure in Step 2, do not save in Step 1 — your Step 2 work will be discarded. Click Next to Step 4 or Step 5 and save there to commit everything.

There are no Save buttons in Step 2 or Step 3. You always advance via Next; the actual commit happens at Step 4 or Step 5.

Leaving without saving discards everything. Closing the tab, refreshing, or clicking away triggers a confirmation. If you confirm Leave (or the browser dialog), every unsaved change in every step is lost. The form returns to its last-saved state.

9. Snapshot Behavior and Ongoing Visits

When an employee successfully checks in to a channel, the system snapshots the entire form configuration at that moment — structure, target, availability, assignment, training material, and even compound configurations. This snapshot is bound to that specific visit.

The result: mid-visit changes do not affect the visit in progress. If you edit a form while a field employee is partway through filling it out, that employee continues using the version they started with. Your changes only apply to new visits going forward.

This protects employees from disruption — no questions disappearing while they’re filling them in, no targets changing, no logic suddenly behaving differently. It also protects data integrity: the submission record reflects the form definition that was in effect at the time the data was captured.

10. Assignment Scopes

A form’s distribution is determined by two layers in Step 5:

Channel scope — choose between:

• All Channels — every channel in the system, including new ones added later (auto-synchronized).
• Specific Channels — manually picked channels, with the option to filter the picker by channel attributes (Group, Type, Stage, Category, Sub-Channel, Classification).

Employee scope (within those channels) — choose between:

• All employees in channel — every employee assigned to the selected channels.
• Employees in specific working group — filter to a specific Working Group → Level → Node combination.

Combining both gives you precise control. For example: “All Channels, but only employees in the Sales Working Group at the Senior Sales Rep level under the Jakarta Node.”

11. Historical Integrity Rules

Past submissions are sacred — once a form has been submitted, its data and structure are preserved indefinitely, regardless of what happens to the form, the employee, the channel, or the assignment afterward.

Specifically, submitted reports remain accessible and exportable when:

• The form is renamed, unassigned, or deleted in the Client Portal.
• The channel becomes inactive or is deleted.
• The employee becomes inactive or is removed.
• The working group, level, or node used in assignment is deleted.
• The form template is updated to a new version.

When viewing a historical submission, the system loads the form structure from the snapshot version used at submission time — not the current version. If V1 had ten questions and V3 only has eight, opening a V1 submission still shows all ten with their original answers.

The form template name updates to the latest version in display (so the list stays current), but the underlying structure and answers stay locked to the original.

12. Compound Input Types in Brief

A Compound Input Type is a reusable group of questions that operates on items from a database — for example, “Stock Check per SKU” where the same set of questions (current stock, expiry date, photo) is repeated for each selected product.

Key concepts:

• Item source. Compound items come from one of five sources: Channel, Asset, Employee, Working Location, or Custom Database. You can use All Data or filter by criteria.
• Reusability. Once you create a compound, you can drop it into any number of forms by selecting it as the input type of a question.
• Dedicated page in forms. When a compound is added to a form, the system creates a dedicated Compound Page for it. Other questions cannot share that page.
• Nesting. A compound can include another compound as a nested element, but only one level deep — no nested compounds inside nested compounds, no self-references, no circular chains.
• Shelf Share is a specialized compound for shelf-placement reporting. It’s exclusive: a Shelf Share compound cannot contain any other input type alongside it.
• Mobile rendering. On mobile, compound pages show an action button (e.g., + SKU). The employee taps it to pick items from the database; each selected item generates its own answer section. Auto-calculations apply for Shelf Share (total length and per-item percentage update live).

Compounds have their own list and creation flow under Settings → Task Operations → Form → Compound Input Type. They’re versioned separately, and editing a compound automatically propagates a new version to every form that uses it.

Where to Next?

Now that you have the conceptual foundation, you’re ready to start working with Forms hands-on. Choose your next read based on what you need to do:

• Browse and find existing forms → How to Navigate the Form Template List
• Create a new form from scratch → How to Create a Form Template
• Build a reusable item-based question group → How to Create and Use a Compound Input Type
• Edit an existing form → How to Edit a Form Template
• Export submitted data → How to Run a Task Report Export
• Look up specific limits, error messages, or rules → Forms Reference: Validation, Errors, Limits & System Behavior