Builder Lesson 32 of 63 ⏱ 8 min ▶ Video

Criteria and prompts — filtering your data

Lesson summary

Two flavors of filtering — hardcoded (the report always filters this way) and dynamic (the user picks at run time). The Criteria Builder handles both. This lesson covers when to choose each, the wildcard syntax that trips up everyone the first time, and the one rule about dashboards.

By the end of this lesson

  • A report filtered to exactly the subset you care about
  • Optional dynamic prompts so users pick the filter at run time

You'll need

  • A report with the columns you want — easiest with the one from Lesson 2
  • Composer role on the app

Background

The report you've been building since Lesson 1 still returns every row in the underlying table — possibly 72,000 of them. Criteria is how you cut that down to the rows that matter. Add criteria lives in the same action menu you've already been using on each field card; the rest of the work happens in a sidebar called the Criteria Builder.

Before any clicking, one decision shapes everything else: should this filter be hardcoded (the report always filters this way) or dynamic (the user picks at run time)?

Hardcoded

The report always filters this way. Readers see results without picking anything.

Best for:
• A specific subset that never changes
• Reports going onto a dashboard
• Embedded views in another product
• Anything where the audience shouldn't have to think about the filter

Prompt for Value

The user picks the value at run time. Same report shape, different filter each run.

Best for:
• One report serving many use cases
• Standalone library reports
• Scheduled exports parameterized by date/customer/region
• Embed objects that pass parameters in

The dashboard caveat: if a report is going onto a dashboard, don't put dynamic prompts on it. Dashboards have their own filtering system (covered in Module 11), and a prompted report inside a dashboard makes users answer the same question twice — once at the prompt, again at the dashboard filter. Hardcode it instead. If users genuinely need to vary something on a dashboard, that's a dashboard filter — not a report prompt.

One last orientation note before the click-by-click: the wildcard for LIKE matching is %, not *. SQL convention, not the asterisks you'd type in other places. %Groc% matches any text containing "Groc" — Shoplite Grocery, Genesis Groceries, anything with that substring. Get the wildcard wrong and your LIKE returns nothing; it's the most common stumble in this lesson.

Haven't watched the video yet? Start there — about eight minutes, click-by-click. The rest of this page anchors what you saw.

Stuck on a particular criterion — date intelligence, LIKE matching, prompt behavior? Email team@dashboardfox.com. Real human, same business day.

Do it

  1. Open the Criteria Builder

    On the card you want to filter on, open the action menu (the three dots on the right) and click Add criteria. The Criteria Builder sidebar opens on the right.

    It has two sections stacked top to bottom:

    • Current Criteria — a table of criteria already on this card (empty on first open). Edit (pencil) or delete (trash) rows from here.
    • Edit Criteria — the form where you build a new criterion. Has dropdowns for Logical Filter, Conditional, and Operator, plus a value input that changes shape based on the operator and field type.

    Two buttons matter at the bottom of the Edit Criteria form: Add To Table (commits your current criterion into the Current Criteria table above) and Back. At the very bottom of the sidebar: Cancel and Save & Apply. Save & Apply stays greyed out until you've used Add To Table at least once — that's the cue that catches most first-time users.

  2. Build a hardcoded date criterion

    Open Add criteria on a date field — your Open time column is a good candidate. In the Edit Criteria form:

    • Logical Filter: And. (The first criterion is always AND — only later criteria expose OR.)
    • Conditional: Is for "I want rows matching this", or Is Not to exclude them.
    • Operator: Equal. For date fields, Equal opens a list of predetermined date ranges instead of asking you to pick a single date — Today, Yesterday, This Month, Last Month, Last 3 Months, Year to Date, and so on. Type to filter the list ("month" narrows it to just the month-based ranges).
    • Value: pick Last 3 Months (or whatever range you want).

    Click Add To Table. The criterion moves into Current Criteria at the top. Click Save & Apply. The sidebar closes, the preview updates, and the card now shows a criteria badge like ? = [Last 3 Months] — confirmation the filter is active.

    Click View Full Document to confirm the row count dropped. What was 72,000 rows might now be 500 or 5,000.

  3. Add a hardcoded character criterion with LIKE

    Open Add criteria on a character field — your Customer column works. The Operator dropdown changes for character fields. Three you'll use most:

    • Equal — pick one value from a list. Use when you want exactly one customer (or status, or category).
    • In List — match against several values. Use when you want exactly two or three known customers.
    • Like — partial-match against a typed pattern. Use when you don't know all the spellings or you want to match a substring.

    For Like, the value field accepts a SQL-style pattern with % as the wildcard:

    • %Groc% — matches any value containing "Groc" anywhere (Shoplite Grocery, Genesis Groceries, Grocery Plus).
    • Groc% — matches values starting with "Groc".
    • %Groc — matches values ending with "Groc".

    The pattern is case-sensitive depending on your data source — some databases treat groc and GROC as the same, others don't. Match the case you see in the data; if you're unsure, try one form, then the other.

    Click Add To Table, then Save & Apply. Two criteria now show on the card (the date filter from step 2 and this character filter), and the preview reflects both.

  4. Turn a criterion into a dynamic prompt

    Same card, open Add criteria again. In the Current Criteria table, click the pencil (edit) icon on the criterion you want to make dynamic. The Edit Criteria form re-populates with that criterion's settings.

    At the bottom of the form, two checkboxes:

    • Prompt for Value — check this. The criterion now asks the user for the value at run time instead of using the hardcoded one.
    • Enable Prompt Skipping — leave unchecked unless you want users to be able to skip the prompt and pull every row. Leaving it off forces them to pick — useful as database protection on big tables.

    Click Add To Table (it replaces the existing criterion since you were editing), then Save & Apply.

    Critical step before testing: save the report itself (red Save button → Overwrite). Dynamic prompts only fire when the report has been saved with the prompt in place. If you skip this and click View Full Document, you won't see the prompt — and you'll think it's broken.

    Now click View Full Document. A prompt panel appears asking for the value. Pick one (or leave the predetermined range it suggests), click apply, and the report runs filtered to your choice. A small filter bar appears at the top of the document so users can change their answer without re-opening the prompt.

  5. Skip Initial Prompts for a smoother run

    By default, a prompted report opens to its prompt panel and waits for the user to pick. That's fine for one-off runs, but it adds friction if users mostly want to scan first and refine later. Composer has a setting to flip the order: load the report immediately, show the filter bar at the top, let users adjust if they want.

    From the top-right toolbar, click ActionsSettings. Expand Advanced Options. Toggle Skip Initial Prompts. Save & Apply.

    Run the report from the library now — it loads straight to results, with the prompt visible as a filter bar at the top. Users who want to filter further still can; users who just want to scan the default view aren't blocked.

    The Advanced Options panel also surfaces Smart Prompting, which is the dashboard-context cousin of this lesson. It's deliberately out of scope here — covered in Module 11 alongside dashboard filters where it actually shines.

Make it real

Habits that keep criteria from becoming a maintenance burden.

Hardcode while building, flip to prompt at the end

Dynamic prompts force a save-then-test loop — every iteration on the report requires saving before View Full Document will show the prompt. That's slow when you're still shaping the report. The workflow that saves time: build with everything hardcoded (a real value, a real date range), iterate quickly with the preview and View Full Document, and only flip the criteria to Prompt for Value when the report is otherwise done. Final save, final test, ship it.

The wildcard is %, not *

Tattoo this somewhere visible. SQL uses % as the wildcard in LIKE patterns; asterisks (*) match nothing. If your LIKE returns zero rows and you expected matches, check the wildcard first — it's the answer roughly half the time.

For "contains" matching, wrap both sides: %Groc%. For "starts with", trailing only: Groc%. For "ends with", leading only: %Groc.

Use predetermined date ranges, not raw dates

Composer's date intelligence — This Month, Last 3 Months, Year to Date — automatically rolls forward. A report set to Last 3 Months always means the last 3 months relative to when it runs, not a frozen January–March window. Hand-picked date ranges go stale; predetermined ranges don't. Default to the predetermined options for any time-based filter unless the report is intentionally about a fixed historical period.

Enable Prompt Skipping is a database-protection call

Leaving Prompt Skipping off forces the user to pick a value before the query runs. That matters when your underlying table has millions of rows — a user who hits "skip" pulls all of them, the database works hard, and they probably didn't want that anyway. On small tables, skipping is harmless. On big ones, force the pick.

No prompts on dashboard-bound reports

A report inside a dashboard widget has the dashboard's filter context wrapping it. If the report also has its own prompt, you've stacked two filter systems and users have to think about both. Hardcode any filter the report needs at build time; use dashboard filters in Module 11 for the runtime variation. The exception is Smart Prompting (also Module 11), which is purpose-built for the dashboard pattern.

If you're stuck

The classic stumbles, in roughly the order they show up.

My LIKE returns nothing

You used * as the wildcard. SQL uses %. *Groc* matches nothing; %Groc% matches everything containing "Groc". This is the single most common stumble in this lesson. Fix the pattern, Save & Apply, run again.

My LIKE matches some but not all the values I expected

Case sensitivity, almost always. Your data source is treating groc and Groc as different strings. Match the case you actually see in the data — if the values are Shoplite Grocery, write %Groc%, not %groc%. Some databases are case-insensitive by default and this won't bite you; others are case-sensitive and it will. When in doubt, try one form, then the other.

Save & Apply is greyed out

You filled in the Edit Criteria form but didn't click Add To Table. The button stays grey until at least one criterion has been moved into the Current Criteria table above. Click Add To Table; Save & Apply lights up.

My dynamic prompt isn't showing up in View Full Document

You added the prompt but didn't save the report afterward. Dynamic prompts only fire when the report has been saved with the prompt in place. Click the red Save button (Overwrite), then View Full Document. The prompt panel appears.

My date range doesn't include the rows I expected

Two possibilities. First — predetermined ranges like Last 3 Months are calculated relative to today's date, not your data's most recent date. If your data ends a month ago, Last 3 Months includes that gap. Second — time-zone behavior on date fields. Today in browser-local time isn't the same as Today in the database's time zone, and rows near midnight can fall on either side. Module 3's formula fields lesson covers the time-zone setup.

I want users to pick a filter on a dashboard, not on the report

That's a dashboard filter, not a report prompt. Hardcode anything the report needs at build time; build the user-facing pick into the dashboard. Dashboard filters in Module 11 is the right tool. For the more advanced case where the dashboard needs to push a filter selection into the report's criteria at run time, that's Smart Prompting — also Module 11.

None of these match my situation

Email team@dashboardfox.com with the criterion you're building (a screenshot of the Criteria Builder helps) and what's happening vs what you expected. Same business day reply.

7-day free trial — no credit card

Built lean. Priced fairly. Supported by humans.

Full access to all features. No credit card required.

Prefer no subscriptions & full control? Self-hosted from $4,995 one-time →

Click once to extend to 14 days — need more time? Just reach out.

25+ years building BI tools Support from the team that builds it Available in US & EU regions
DashboardFox mascot