Using a SharePoint Choice Column as the “Workflow Engine” for a Modern List (SharePoint Online + Power Automate + Power Apps + Azure DevOps)

In SharePoint Online (Microsoft Lists), a Choice column is one of the simplest—and most powerful—ways to standardize process states and drive automation. When you treat a Choice column as your “single source of truth” for status, you get:

• A consistent, human-friendly state machine (e.g., Draft → In Review → Approved/Rejected)
• A clean trigger point for Power Automate flows (notifications, approvals, integrations)
• A predictable UI control for Power Apps forms (validation, conditional visibility, guided actions)
• A stable integration field to synchronize status to external systems (e.g., Azure DevOps discussion/comments)

This article shows an end-to-end pattern: designing the Choice column, using it as workflow control, formatting it for clarity, building Power Automate flows around it, enhancing the form with Power Apps, and finally pushing status changes into Azure DevOps as a comment in the work item discussion.

All examples below use neutral placeholders like https://contoso.sharepoint.com/sites/ExampleSite and Example List.

1) Why a Choice Column is a Workflow “Backbone”

A Choice column is more than a dropdown—it’s a governance mechanism:

• Data consistency: users cannot type random status values.
• Automation stability: flows can rely on known states.
• Reporting readiness: Power BI / views can group and filter reliably.
• Low friction: no custom code required to start.

The key is to treat it as a state model, not just a label.

2) Designing the Workflow Choice Column (States + Rules)

Recommended column design

Create a Choice column named:

• Column name: WorkflowStatus
• Type: Choice (dropdown)
• Default value: Draft

Example state set (simple but effective)

• Draft
• Submitted
• In Review
• Approved
• Rejected
• On Hold
• Cancelled

Add a second column (optional but highly useful)

To avoid ambiguity and improve auditing:

• WorkflowStatusChangedOn (Date/Time)
• WorkflowStatusChangedBy (Person)

Your flow (or Power Apps form) updates these automatically whenever WorkflowStatus changes.

3) Triggering Power Automate from the Choice Column

Power Automate’s SharePoint connector gives you triggers like “When an item is created or modified” and actions to read/update items. (Microsoft Learn)

The baseline pattern

1. Trigger: When an item is created or modified (SharePoint)
2. Condition(s): If WorkflowStatus equals a specific value
3. Actions: Send email/Teams notification, create approvals, update fields, call external APIs, etc.

Best practice: trigger only when the status changes

Instead of running on every modification, focus the flow when the Choice value changes. This reduces noise and prevents re-processing.

There are two common approaches:

Approach A: “Status changed?” using change tracking

Use actions that compare “before vs after” (commonly used in SharePoint-driven workflows). This is the cleanest approach for avoiding duplicate actions.

Approach B: “Gatekeeping” with a flow-side field

Store the last processed status (or last processed timestamp) in a hidden column like WorkflowLastProcessedStatus. If WorkflowStatus ≠ WorkflowLastProcessedStatus, then run workflow steps and update WorkflowLastProcessedStatus.

This is simple and extremely reliable.

4) Workflow Examples in Power Automate (Real Scenarios)

Below are examples that work well in real operations.

Example 1 — Notifications when moving to “In Review”

Trigger: item created/modified
Condition: WorkflowStatus equals In Review
Actions:

• Post a Teams message to reviewers
• Email the assigned reviewer
• Update WorkflowStatusChangedOn/By

This uses the SharePoint connector triggers/actions described in Microsoft documentation. (Microsoft Learn)

Example 2 — Approval workflow using the Choice column as the controller

Condition: WorkflowStatus = Submitted
Actions:

• Start an approval
• If approved → update WorkflowStatus = Approved
• If rejected → update WorkflowStatus = Rejected
• Write outcome to comments/notes field

Result: the SharePoint list remains the system of record, and the Choice column is the workflow state that anyone can understand at a glance.

Example 3 — Sync status to another system

When WorkflowStatus changes to Approved, you can:

• Create/update a record elsewhere
• Call an Azure Function / API
• Create a DevOps task
• Update a DevOps work item and add a comment (we’ll do this later)

5) Power Apps: Using the Choice Column to Build a Guided Form Experience

Power Apps integrates tightly with SharePoint lists, and you can customize list forms to guide users through your workflow. (Microsoft Learn)

Key form patterns with a Choice column

Pattern A — Conditional visibility

Show/hide fields based on status, for example:

• Show “Reviewer Notes” only when WorkflowStatus = In Review
• Show “Rejection Reason” only when WorkflowStatus = Rejected

Power Apps supports reordering cards and controlling visibility/behavior of fields in customized SharePoint forms. (Microsoft Learn)

Pattern B — Lock down edits after approval

When status is Approved, set most controls to DisplayMode.View so users can’t accidentally change fields after finalization.

Pattern C — Buttons to move states safely

Instead of letting users pick any value in the dropdown, provide buttons:

• “Submit”
• “Send to Review”
• “Approve”
• “Reject”

Each button:

• validates required fields
• updates WorkflowStatus
• writes audit metadata

This reduces human error and enforces rules.

6) Formatting the Choice Column (JSON) to Make Workflow Instantly Readable

SharePoint column formatting lets you customize how a field is displayed using JSON—without changing the underlying data. (Microsoft Learn)

Why format WorkflowStatus?

• Users can see status quickly (badges/pills)
• Lists become scannable
• “At risk” statuses stand out visually

Example: badge/pill-style formatting (generic)

Below is a practical JSON formatter that:

• renders the Choice value as a badge
• changes styling based on the status text

{
  "$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
  "elmType": "div",
  "style": {
    "display": "inline-block",
    "padding": "4px 10px",
    "border-radius": "999px",
    "font-weight": "600",
    "font-size": "12px"
  },
  "attributes": {
    "class": "=if(@currentField == 'Approved','sp-field-severity--good'," +
             "if(@currentField == 'Rejected','sp-field-severity--blocked'," +
             "if(@currentField == 'In Review','sp-field-severity--low'," +
             "if(@currentField == 'Submitted','sp-field-severity--warning'," +
             "'sp-field-severity--neutral'))))"
  },
  "txtContent": "@currentField"
}

Notes

• This formatting does not change the stored value, only the UI rendering. (Microsoft Learn)
• Advanced formatting concepts (including reuse and references) are documented in Microsoft guidance. (Microsoft Learn)

7) Sending the Choice Status into Azure DevOps “Discussion” (as a Comment)

Many teams want a SharePoint workflow state to appear in Azure DevOps so engineers and PMs don’t have to “check two systems.”

The clean approach: add a Work Item comment via REST

Azure DevOps provides a REST endpoint to add a comment to a work item. (Microsoft Learn)

What you do in Power Automate

1. Trigger when SharePoint item changes and WorkflowStatus changed
2. Compose a message like:

[SharePoint Workflow] Status changed to: Approved | Item: <link> | By: <person> | On: <timestamp>

3. Call Azure DevOps REST API “Add Work Item Comment”
4. (Optional) also update work item fields (State, Tags, etc.) using the Azure DevOps connector

The Azure DevOps connector for Power Automate is documented here. (Microsoft Learn)

Example: Comment text template (best practice)

Include enough context so DevOps users can understand without opening SharePoint:

• New status
• Old status (if you track it)
• Link to the SharePoint item
• Who changed it
• When it changed
• Optional: reason/notes fields

Why comments instead of overwriting “Discussion” directly?

In Azure DevOps, “Discussion” is effectively represented through history/comments patterns. Adding a comment is safer because it preserves timeline instead of replacing content. The REST API explicitly supports creating comments on work items. (Microsoft Learn)

8) Putting It Together: A Reference Architecture

SharePoint List

• WorkflowStatus (Choice) ← the workflow state machine
• WorkflowStatusChangedOn (Date)
• WorkflowStatusChangedBy (Person)
• Optional: WorkflowLastProcessedStatus (Choice/Text)

Power Apps (Form)

• Guides user actions (buttons, conditional fields)
• Prevents invalid transitions
• Improves UX and reduces training cost (Microsoft Learn)

Power Automate (Automation)

• Watches for status transitions (Microsoft Learn)
• Sends notifications/approvals
• Writes audit fields
• Posts DevOps comments via REST (Microsoft Learn)

Azure DevOps

• Receives workflow events as comments
• Optionally syncs state/tags using connector actions (Microsoft Learn)

9) Common Pitfalls (and How to Avoid Them)

Pitfall 1: Flow loops (update triggers itself)

If your flow updates the same item, it retriggers.

Fix:

• Use “last processed status” guard
• Or use trigger conditions / change detection patterns
• Or split into “human updates status” vs “system updates metadata” and guard with a hidden boolean flag.

Pitfall 2: Users jump states incorrectly

If users can pick any Choice value, they can jump from Draft → Approved accidentally.

Fix:
Use Power Apps buttons and disable the dropdown or restrict transitions using validation.

Pitfall 3: Too many flows

One flow per status gets messy fast.

Fix:
Use one orchestrator flow that routes behavior by status and transition.

Final Summary Tables

A) Implementation Steps (Practical Checklist)

B) Key Microsoft Learn References Used