Expectations
Expectations let you define what correct file delivery looks like for your site, evaluate the files available for each delivery window, and keep a record of the result.
Expectations can detect a missing delivery even when there is no file activity to trigger an alert. This helps you identify a missing vendor feed or a late compliance package before downstream processing fails.
With Expectations, you specify which files must arrive, where, and when. Files.com evaluates each delivery window against the criteria you define and records the outcome. An evaluation records whether matching files were available on time and in the right shape, were late, failed validation, or were absent when evaluated. When a scheduled delivery fails, an Incident is opened so your team can investigate and respond.
Expectations are most valuable for critical, recurring file flows where a missed or malformed delivery causes real downstream damage. Common examples include vendor feeds, order ingestion, finance batches, compliance packages, and partner integrations. You get an explicit definition of what correct delivery looks like, a record of every window's outcome for audits and investigation, and a clear signal that data is ready (or is not) before downstream processing begins.
Incidents keep active problems visible and distinct from historical records, so your team always knows what still needs attention.
How Expectations Work
An Expectation monitors a defined scope of files within a recurring time window and evaluates whether those files meet your success criteria. Each Expectation has three components: success criteria that specify what a valid delivery looks like, a time window that says when files are expected to arrive, and a scope that defines the folder path and file pattern to monitor.
File-level criteria verify information about the files themselves, including how many arrived, how large they are, and how they're named. Content Validation criteria verify the data inside those files using custom TransformScript validation.
When a window closes, Files.com evaluates the matching files still present in the monitored scope against your criteria and records the result as an Evaluation. Files deleted or moved outside that scope before the closing evaluation are not counted, even if they arrived during the delivery window. This check establishes whether the expected data is available for use. If a scheduled window fails, an Incident is opened to track the outstanding problem until it is resolved.
To get notified when an evaluation result occurs, use Event Channels. Subscribe to Expectation Evaluation events (Success, Late, Missing, Invalid) or Expectation Incident events (Open, Acknowledged, Snoozed, Resolved) and route them to a webhook, Slack, Teams, SNS, Pub/Sub, or email target.
Expectations are a monitoring layer. They do not move or modify files. Think of them as sensors that determine whether expected data is present and acceptable.
Site Administrators can create and manage all Expectations on the site. Workspace Administrators can create and manage Expectations for folders within their Workspace.
Expectation Results
Each closed window produces one of four results.
| RESULT | MEANING |
|---|---|
| Success | Matching files were present, met the deadline when one applied, and satisfied all criteria. |
| Late | Matching files were present, but at least one arrived after the deadline within the late acceptance window. All criteria were satisfied. The SLA was missed, but the data is valid. |
| Missing | No files matched the configured scope and time window at the closing evaluation. |
| Invalid | Matching files were present, but one or more criteria were not satisfied. |
A Missing result does not prove that no files arrived: matching files may have arrived and then been removed before evaluation. An Invalid result means matching files were present but failed one or more criteria. For example, removing part of a delivery can produce Invalid if the remaining files do not satisfy a file-count or required-file rule.
Manual and upload-triggered windows do not produce Late results, since those triggers have no schedule-defined deadline.
Delivery Windows in Practice
Choose the trigger and criteria for the question you need the monitor to answer. A scheduled deadline, an upload burst, and a complete batch impose different checks.
Scheduled Deliveries
For a partner's daily CSV due before processing begins, a scheduled Expectation can check the folder and filename pattern, then validate the columns and values the application needs. Separate Expectations give each partner an independent outcome. The same arrangement can monitor an hourly status export: when the system stops producing it, the missing window opens an Incident even though no upload occurred to trigger a notification.
Keep matching files in scope until evaluation closes, and configure the response to a failed result separately. Expectations detect and record the problem; they do not hold files or prevent downstream processing from starting.
Complete Batches
A batch may require a manifest, a specific number of data files, and no partial files. Combine those file-level criteria with whole-batch content validation when the manifest's totals must reconcile with its accompanying data. File presence and content agreement are different checks; neither establishes acceptance by the receiving application.
Irregular Uploads
When a partner sends orders in bursts without a fixed deadline, an Upload trigger opens a window at the first matching upload and evaluates after the configured quiet interval. It records whether the files present at closure meet the criteria. It cannot detect a partner who never starts a batch, because no upload opens the window. Use a scheduled Expectation when absence itself must be detected.