Skip to main content
Every Data Feed has a Trigger that controls when it runs. There are two top-level modes and five schedule presets.

Trigger modes

Schedule types

When the Trigger is set to On Schedule, pick one of: Schedule type dropdown showing Hourly, Every 4 Hours, Daily, Weekly, and Cron

On-demand refresh

Three ways to manually trigger a feed run:
  1. The Test button at the bottom of the Data Feed editor — runs the request once and shows the response inline (works on Draft and Published)
  2. The refresh icon in the Data Feed editor toolbar (top right of the canvas) — re-runs against the Published configuration
  3. A “Refresh” control in a Studio app that wires up to this feed — built by asking the Composer
A Data Feed must be Published before it can run on a schedule. Hover the refresh icon in an unpublished feed and you’ll see the message “Please publish this data feed in order to trigger a run.” The Test button works on Draft.

Request History

The full history of every sync run for a Feed lives under ⋯ → Advanced → Request History. Each row shows:
  • Run timestamp
  • HTTP status code
  • Number of records returned
  • Duration
  • Error message (if the run failed)
This is the first place to look when a Studio app shows stale or missing data. The same outbound calls also appear in Settings → Logs → Request History for tenant-wide forensics.

Querying the feed’s data

After a Feed runs, its data is available to Studio apps. Two ways to query:
In the Studio Composer, describe what you need:
The Composer translates natural language into queries against your Feed’s data.

Troubleshooting

Check:
  1. Feed is Published (Draft feeds don’t run on schedule)
  2. The Trigger is configured (Schedule + Type, or set to On Demand)
  3. Credentials in the Variables panel are still valid
  4. The source’s API is reachable from Dimension
Resolution:
  • Open the feed editor and click refresh manually — error messages appear in the canvas
  • Re-enter expired credentials and click the lock icon to encrypt
  • Check the Audit Log under Settings → Logs for failed runs
Apps consume data as of the last successful Feed run. If a Studio app shows out-of-date data:
  1. Open the Feed and check its last-run timestamp
  2. Click refresh in the Feed editor to force a fresh run
  3. Reduce the schedule cadence (e.g. Hourly → Every 15 minutes via a Cron expression)
Check the schema mapping:
  1. Open the Feed and verify the Data Path points to the right array in the response
  2. Verify the ID Path points to a unique identifier
  3. Verify Pagination is configured if the source returns more than one page
Test it:The data preview icon in the editor toolbar (top right of the canvas) opens a preview pane showing exactly what records the feed returned on its last run. The icon is disabled until the feed has at least one successful run.
Optimize:
  1. Reduce the Feed’s data volume — add filters to the URL or Params
  2. In Studio prompts, scope queries: “Show Windows devices with critical risk in the last 30 days” instead of “Show all devices”
  3. Use aggregations (count, group by) instead of raw lists where possible

Adjusting frequency vs. cost

More frequent syncs = more API calls = potentially higher records-ingested usage against your quota. Match the schedule to the data’s actual rate of change. Hourly is rarely needed for inventory data; daily is rarely fresh enough for live threat feeds.