App Action Walkthrough: End-to-End Example

This walks through a complete, fully built App Action to show how all the pieces fit together. Rather than covering each component in isolation, this example shows how basic information, inputs, steps, and variables work as a cohesive whole to solve a real problem.

The scenario

A customer contacts support and asks about a specific order. The organization's App Platform is connected to their ecommerce platform via BigCommerce, and the Look Up Customer by Email App Platform Action is already configured. When called, it returns a verbose dataset containing the customer's full profile and their entire order history.

The goal is to build an App Action that takes a customer's email address and a specific order ID as inputs, retrieves the customer's data, filters it down to the single matching order, removes any non-physical items, and returns a clean result the AI can use to respond to the customer.

Basic information

Name: retale_BigCommerce_OrderFilter

Description: Fetch customer data from BigCommerce and filter for a specific order ID.

The name uses a verb + noun format and is specific about what the action does. The description tells Gladly what the action does, what it needs, and what it returns — which helps the AI understand when and how to trigger it during a conversation.

Action name and description for fetching customer data from BigCommerce by order ID.

Inputs

This App Action uses two inputs:

Name	Description	Type	Required
`email`	The email associated with the customer's profile	string	No
`orderId`	The external order ID to filter for	string	Yes

Note that email is not marked as required. This allows the App Action to still run in scenarios where only an order ID is available. orderId is required because the entire purpose of this App Action is to filter to a specific order — without it, the action cannot complete its task.

Input fields for email and order ID with descriptions for user guidance.

Steps

This App Action uses three steps. The first retrieves data from the App Platform, and the two Transformation steps progressively refine that data into a clean, usable result.

Step 1: `customerData` (App Platform)

Purpose: Retrieves the customer's full profile and order history from BigCommerce using their email address.

Configuration:

Gladly App Platform Action: Look Up Customer by Email
Input — Email: $.params.email

This step calls the App Platform Action and passes in the email input using JSONPath syntax. The result is a verbose dataset containing everything the ecommerce platform knows about the customer, including an array of their recent orders. This data is intentionally broad at this stage — the next step will narrow it down.

App platform configuration showing input fields for email and phone number.

Step 2: `filteredOrder` (Transformation)

Purpose: Searches the customer's order history for the specific order matching the orderId input and returns only that order.

JavaScript code snippet for filtering customer orders based on specific criteria.

This step does several things worth noting. First, it checks that the customer data from Step 1 actually exists before trying to use it — if it doesn't, it returns a clear error rather than failing silently. Second, it checks both the internal order ID and the external order ID fields when searching for a match, which makes the filter more resilient. Third, it wraps the result in an order object to make it easy to reference in the next step.

Step 3: `isolatePhysicalProducts` (Transformation)

Purpose: Takes the filtered order from Step 2 and removes non-physical line items, then checks whether the remaining physical products have been fully shipped.

JavaScript code snippet for filtering and processing order products in an e-commerce system.

This step handles two things. First, it filters out line items that aren't relevant to the customer's question — products with zero quantity, shipping protection add-ons, and digital items. This prevents the AI from referencing items that aren't physical products in its response. Second, it checks whether all remaining physical products have been fully shipped by comparing product quantities against shipment records. If they have, it updates the order status to "Shipped" so the AI has an accurate status to report.

Variables

Variables aren't defined in this example. The final Transformation step returns a clean, structured order object that the AI guide is configured to use directly. In cases where you need the AI to reference specific individual values — like a tracking number or delivery date — you would define variables to extract those fields from the final step's output.

What this example demonstrates

Looking at this App Action as a whole, a few patterns are worth carrying into your own builds:

Chain steps with a clear purpose for each. Each step in this example does one thing: retrieve, filter, then clean. Keeping steps focused makes the App Action easier to understand, test, and troubleshoot.

Always validate before transforming. Both Transformation steps check that the data they need actually exists before trying to use it, and return meaningful error messages when it doesn't. This makes failures much easier to diagnose from the Runs page.

Use descriptions that guide the AI. The App Action's description tells Gladly exactly what the action does and what it returns. A well-written description helps the AI trigger the action at the right moment in a conversation.

Only mark inputs as required when truly necessary. The email input is optional because the App Action can still run without it in some scenarios. Being deliberate about required vs. optional inputs gives the AI more flexibility when collecting information from a customer.

Remove noise before it reaches the AI. Filtering out irrelevant data — like digital products and shipping protection items — in a Transformation step means the AI only sees information it can actually use in a response.