Enabling Enterprise-Grade Workflows for AppOmni’s Clients (Incl. Several Fortune 500 Accounts)

Solution Overview

The solution evolved over multiple phases and PRDs, each deliberately designed to address the core themes uncovered through customer research.

Rather than attempting a single, sweeping redesign, me and the fellow PMs focused on correcting foundational UX and mental model issues first, then layering on scalability, flexibility as the platform matured.

Making Workflows Discoverable and Actionable at the Point of Work (Phase 1)

(Themes addressed: Discoverability, Guidance, and Manual overhead)

One of the most immediate gaps identified in research was that customers didn’t lack automation capability—they lacked awareness that it existed and how to use it.

Workflows lived under Orchestrations in the nav, disconnected from where findings were actually reviewed and acted upon.

This forced users to rely on accidental discovery forcing them to check with the AppOmni support team.

To address this, I redesigned the Posture Findings experience to surface workflows directly where action naturally begins.

I introduced Saved Filters as a reusable pattern that allowed users to define meaningful slices of findings once and reuse them across workflows. (See design below)

The Saved Filters pattern became the connective tissue between detection and action.

From these saved filter sets, users could now: clearly see that workflows were supported, and initiate workflow creation directly, without navigating away from their context.

In parallel, I added a Create Workflow CTA directly on the Posture Findings page, ensuring workflows were visible and discoverable even for users who hadn’t yet created saved filters.

This shift directly addressed a recurring research theme: customers wanted guidance embedded into the product flow—not hidden behind navigation or documentation.

Redesigning Workflow Creation Around Intent, Not Configuration (Phase 1)

(Addressing complexity, extensibility, and future scalability)

The workflow creation experience itself required a fundamental rethink.

Previously, the wizard began by asking for a name and description—before users had clarified what they were responding to or where the output should go.

This reflected an object-first mindset rather than an intent-first one.

I redesigned the wizard to start with user intent.

‍Step 1: Define the Source and Destination

Users now begin by selecting:

1. the source of events (Posture Findings initially, with future support for Threats, Identities, Discovery, etc.),

2. the connection (existing or newly created account).



3. destination (Project and Issue type for Jira vs record type for ServiceNow)

This step was intentionally designed to lay backend foundations so future product teams could plug their domains into the same workflow system without redesign.

‍Step 2: Define auto-ticketing rules

Users then select or reuse saved filters to define:

1. which findings or occurrences should trigger the workflow

2. and whether tickets should be created at the finding level or occurrence level.


This made workflows reusable, composable, and consistent across domains.

Step 2: Configure Field mapping

Field mapping is configured inline, eliminating the need for a separate “template” abstraction and keeping configuration aligned with user intent.

Step 4: Review, Test, and Activate

The final step allows users to validate configuration, test the workflow, and activate it confidently—reducing risk before automation goes live.

Execution history and visibility into errors
‍
‍Once the workflow foundation was in place, the same system was extended to support notifications—without creating a parallel feature.

From the same entry points, users could now create workflows for Slack, Microsoft Teams, Email, and Webhooks.



The wizard dynamically adapted based on destination.

For notification workflows, users could:

1. configure multiple notification rules within a single workflow,

2. control cadence, severity, and scope, choose real-time vs digest delivery,

3. include structured attachments (CSV/XLSX),

4. and route messages to teams without requiring AppOmni user accounts.


This directly addressed customer requests for targeted, actionable communication without noise.

Manual Ticketing at the Point of Work (Phase 2)

While workflows enabled automated ticketing at scale, user research revealed a distinct segment of AppOmni customers who actively triaged and managed findings on a daily basis.

As both Product Manager and Principal UX Designer, I made the decision to support manual ticket creation directly from the Posture Findings page, aligning the product with how this segment already worked.

From the findings table, users can select one or more findings and initiate Create Ticket. This opens a contextual modal where they choose an existing Jira or ServiceNow workflow.

Once selected, the modal surfaces the destination project or record type defined in the workflow and the associated field mappping.