✔ Checklist Custom Statuses

We generally advise against using custom checklist statuses.

The XML configuration section of a Checklist definition can be used to define custom statuses.

<p>
  <k>status</k>
  <v>
    <t icon="Awaiting">Not Started</t>
    <t icon="Awaiting">Half-Complete</t>
    <t icon="Awaiting">Two-Thirds Complete</t>
    <t icon="Received">Complete</t>
  </v>
  </p>

After adding the XML above, Awaiting status will be available, but Received, Received Copy, and Waived will disappear.

CJ filters will not automatically pick up your new statuses; you must create your own subquery filters.

🐞 Custom statuses can introduce funky edge cases, like checklists with the wrong icon for a standard status.

Scenario

Custom checklist statuses are in use for a long time. You wish to revert to the default statuses.

• Removing the status XML will cause any checklist items using a custom status to appear to revert to Awaiting. However, the custom value is still stored in [checklist].
• You cannot use rules to correct statuses in Inactive rounds, as checklist rules don’t run in inactive rounds.
• Batch management from an Application-scoped query does not work; perhaps it cannot Force?

Attempts to update via custom SQL in a portal have so far been unsuccessfully. Edits to the [status] field don't stick. Maybe the trigger requires a corresponding activity?

Inactivating a checklist item definition will not remove it from applications.

Checklist items added individually, either via form rules or via system rules, will have the Edit option. Checklist items added via groups rules will not show the Edit option.

Related Links

Rules that change Checklist Status's to Custom Text (🔐 requires login)