Choose the source representation before choosing the automation. A feed item is not the full article, and an unchanged excerpt is not proof that every part of a web page stayed the same.

Try the smallest free method first

For a short list of sources, an ordinary feed reader can be enough to follow RSS or Atom entries. For a static page, save two authorized HTML or text observations and compare the same relevant region locally.

Write down what you actually collected. A feed reader may expose only titles and summaries. A saved HTML response may omit text assembled later by JavaScript. Neither representation automatically describes the entire published experience.

For a manual review sheet, useful columns are source, observation time, input type, collection outcome, comparison scope, evidence link and reviewer decision. Add a separate “unavailable or incomplete” state instead of treating every empty result as “no change”.

Example: one announcement, two evidence surfaces

Imagine an invented supplier publishes an RSS entry announcing a delivery-policy update. Its summary says “Delivery terms updated”, while the linked static page changes a delivery window from five days to seven.

The feed workflow can identify a new or updated feed entry. It cannot supply the complete page difference from that summary alone. The page workflow can compare the selected static text, but it does not establish whether every announcement channel was updated.

Keep both records if the review needs both questions. Link them by source and time in your review notes; do not merge them into an unsupported statement that the whole policy was collected and understood.

RSS and Atom evidence

Licensed Industry RSS Evidence Delta Feed reads its documented feed titles and summaries. Use the existing feed example to inspect the input and output fields.

Check the feed's own terms before adapting it. “Licensed” in a product name does not grant you a licence to reuse somebody else's material. Do not assume that an accessible summary authorizes collecting or republishing the full article.

Use keywords where they help your review, but record that filtering can exclude items. Keep a stable monitor key for the same source and workflow; use a fresh key when switching away from demonstration data or changing what you intend to monitor.

A feed can also change its identifiers or shorten its retained history. An item no longer appearing in a bounded feed does not necessarily mean that the publisher withdrew the article. Follow the evidence link before making that interpretation.

Static policy-page evidence

Authorized Policy Page Change Audit compares static HTML text. It does not render page JavaScript or access signed-in pages.

Its documented defaults exclude scripts, styles, navigation, headers and footers. Changes confined to those areas will therefore not appear. Select the relevant region and exclude noise deliberately; a selector that is too narrow can hide the text you intended to review.

The policy-page example uses a public terms page. For your own source, confirm authorization and use a new monitor key when changing the source or comparison settings. Keep the same page ID and key for later observations of the same configuration.

Interpret held and incomplete outcomes

Inspect OUTPUT and diagnostics, not only the platform's successful-run label. The documented page workflow can hold a comparison when a page is incomplete, unexpectedly empty or reduced by more than 70%.

Investigate the source, selected region and truncation before considering an explicit override. Turning on an empty-input or large-reduction acknowledgement merely to force an answer can convert a collection fault into a misleading change record.

For either input type, distinguish four statements: the source was requested, the intended representation was collected, a comparison completed, and a human reviewed the meaning. Evidence for one statement is not automatically evidence for the next.

Decide whether the hosted workflow fits

These Actors are useful for structured evidence that you can pass to a review queue. They are not a visual website monitor, a full-text reading application or an automatic interpretation of contractual changes.

Review the live Pricing tab and maximum cost before running. Completed checks may be billable even with unchanged text or no matching entry. Starts, storage and later dataset access or exports can add platform usage costs. Retrieve existing outputs before starting another run.

Disclosure: I publish the linked Actors. This article was prepared with AI assistance and checked against the source-monitoring guide. The supplier example is invented; no customer result, legal interpretation or sales outcome is implied.

This walkthrough uses invented catalog rows. It provides a review procedure, not an instruction to update a live shop.

Start with a free comparison

For a small export, a spreadsheet with exact string lookups may be enough. Put the earlier and later versions on separate sheets, check for duplicate identifiers, and compare the same fields. A short local script is another option if you already maintain one. You do not need a hosted workflow just to inspect a handful of rows.

Before comparing anything, answer three questions:

• Do both exports cover the same intended supplier, store, region and time window?
• Is every SKU a unique string?
• Did both exports finish successfully?

Keep "00123" as a string. Converting it to the number 123 changes the identifier. Do not silently merge duplicate SKUs; stop and resolve them. Keep a missing field separate from an explicitly empty or null value.

Work through one invented change set

Suppose the earlier export contains:

The later export contains:

For these two complete exports, the review queue contains one changed SKU, one removed SKU and one added SKU. That conclusion describes the supplied arrays. It does not prove what happened in the supplier's production inventory.

If the later export stopped halfway through, an absent SKU would instead be a collection problem. A comparison cannot independently establish that your upstream export was complete.

Choose the workflow that matches your input

Recurring feed observation. Authorized Catalog Feed Change Audit accepts the documented authorized JSON or CSV feed/export workflow. Its first observation establishes a baseline. Later observations reuse a stable monitor key to identify changes.

Use a new key when switching from fictional input to a real source, or changing the intended supplier or workflow. Otherwise, your first real comparison may be against the demonstration. Authenticated feeds are not supported: do not put passwords, tokens or secret query parameters into a feed URL.

Two complete JSON snapshots. Product Catalog Diff by SKU / Revenue Pilot is for an earlier and later JSON array supplied together. It does not fetch product pages, accept CSV or Excel directly, or update your catalog.

Its fictional example uses this input:

{
  "key": "sku",
  "before_complete": true,
  "after_complete": true,
  "before": [
    {"sku": "00123", "price": 19.90},
    {"sku": "00124", "price": 24.00}
  ],
  "after": [
    {"sku": "00123", "price": 21.00},
    {"sku": "00125", "price": 15.00}
  ]
}

Only declare completeness after checking the exports. An intentionally empty catalog needs the documented explicit acknowledgement; an export failure should not be acknowledged merely to get a removal list.

Retrieve evidence before starting another run

For Revenue Pilot, the dataset holds one summary row with counts. The run's default key-value store contains OUTPUT, the detailed JSON with field-level changes. Retrieve the existing result before submitting another comparison.

The documented limits are 10,000 rows per snapshot, 5 MiB input JSON and 16 MiB result JSON. Review the current input documentation before use. A held or rejected result is different from a completed comparison.

One completed Revenue Pilot comparison costs USD0.05 under its existing event, including a comparison with no changes. Check the live Pricing tab and maximum charge first. The separate feed Actor has its own pricing. Platform storage and later dataset reads or exports may have additional usage costs. A new run is a new operation; do not retry an uncertain charge by starting again.

Make the review actionable

Keep the input scope, observation time, source and completeness assessment beside the change queue. Have a person review unexpected removals before importing anything. These tools provide evidence; neither performs the catalog import or changes stock and prices for you.

Open the feed example or the two-snapshot SKU example that matches your input.

Watch the recurring-feed example in 40 seconds

This video follows the recurring Catalog Feed Actor using four fictional SKUs, so a one-row removal stays below its default large-removal threshold. It is separate from the two-array Revenue Pilot example above. The captions are based on offline product-function checks, not a new cloud run or customer results.

Download the 40-second video, follow the two-observation input guide, or try the manual n8n review-queue preview. The n8n transformation has local checks; import and execution in n8n are still unverified.

Disclosure: I publish the linked Actors. This article was prepared with AI assistance and checked against the existing walkthrough and feed guide. The examples are fictional; prior owner checks are not customer outcomes, sales evidence or a performance guarantee.

Keep those two questions separate: what changed in the source, and what does the change justify researching? This walkthrough uses fictional job observations and two different kinds of tools.

A small free workflow is often enough

For a short watchlist, save dated copies of the authorized job-board response and maintain a simple review sheet. Include the board identifier, fetch outcome, completeness assessment and job ID. Compare stable IDs rather than titles, which can change or be reused.

An empty file needs a collection explanation before a business explanation. If the request failed, mark the observation unavailable. Do not replace it with an empty successful snapshot. A spreadsheet row saying “not observed” is more useful than an unjustified “closed”.

This approach is manual, but it makes the uncertainty visible. A hosted Actor is useful when you want the documented structured health and change records; it does not remove the need to inspect source coverage.

Follow one fictional job across observations

Imagine a sample board containing job 101, “Platform Engineer”. All three observations below are deliberately declared complete.

The three-snapshot walkthrough documents this sequence from an owner check using invented input. It is not a record of a real employer or a customer outcome.

A failed or incomplete source does not advance the missing-observation count. Even closed_candidate remains a candidate for review. It is not independent confirmation from the employer that the vacancy has closed.

Before acting, open the original board. Check whether the role moved to another identifier, location, department or requisition. Keep that review decision separate from the automated label.

Use ATS monitoring for source changes

ATS Source Health & Job Delta Feed handles its documented authorized Greenhouse, Lever and Ashby board workflow. Start with the fictional public example, then read the source-health rows alongside the job rows.

Use a new monitor key for your own source, rather than continuing the fictional example's history. Reuse that key for later observations of the same board and workflow. Keep the board ID stable, and only declare a supplied snapshot complete when its intended scope really was collected.

For live boards, permission to use a public source does not mean the Actor signs in on your behalf. Do not supply passwords or tokens in board fields. Minimize any personal details in snapshots, because run inputs and outputs remain in the chosen Apify account.

Use RevOps research for a different question

Salesforce & HubSpot Project Signals / RevOps Radar is an account-research workflow. Its existing example inspects a small Greenhouse starter set and supplies role evidence, source links, cautions and qualification questions.

For your own targets, supply the documented public Greenhouse board URLs or board names and select Use only my boards. Plain company domains, LinkedIn profiles and other applicant-tracking systems are not accepted by this workflow. ATS-monitoring support for another platform does not imply RevOps support for it.

US/UK filters refer to job locations, not headquarters. A score orders a research queue; it is not a purchase probability. A CRM-related role may be worth reading, but it does not prove a project budget, an external supplier requirement or permission to contact someone.

A useful handover records the source and date, the role evidence, what remains unknown, and a question a person could investigate. Avoid turning that handover into automatic outreach.

Check costs and retrieve the existing evidence

Review each Actor's live Pricing tab and set a maximum cost before starting. A successful complete board check or company analysis can be billable even when it yields no relevant change or role. Starts, storage and later output access can add usage costs. The two Actors have different charging rules.

Inspect diagnostics and the run's existing results before restarting. A successful platform run alone is not evidence that every intended source was covered.

Use the RevOps public example to inspect its input shape and output fields. Keep source monitoring, research qualification and any later human decision as separate stages.

Watch the missing-job sequence in 40 seconds

This captioned example uses an invented board and offline product-function checks. It is not a new cloud run, a real employer observation or a customer result. It illustrates the ATS monitoring workflow, not RevOps buying intent.

Download the 40-second video, use the three-snapshot inputs, or try the manual n8n review-queue preview. The preview keeps source health and evidence beside a human decision. Its transformation has local checks; import and execution in n8n are still unverified.

Disclosure: I publish the linked Actors. AI assisted this article, which was reviewed against the ATS guide and RevOps guide. Examples and historical owner checks are not customer results or evidence of sales.

Disclosure: this article was drafted with AI assistance and checked against the linked publisher documentation and recorded owner demonstrations. The publisher maintains the Apify tools discussed here. Examples are fictional or explicitly identified owner tests; they are not customer outcomes. The article is freely readable and is not a claim of savings, demand, compliance or investment performance.

Separate the four questions

Keep these distinctions when moving a result into a spreadsheet, notification or review queue. A row count is a property of the delivered data; it is not automatically a count of every relevant event in the market.

Case 1: a completed recall query that was capped

The publisher's existing supplier-evidence walkthrough records this abbreviated owner-test health row from 27 October 2026:

{
  "recordType": "recall_query_health",
  "status": "completed",
  "scanned": 100,
  "totalAvailable": 247,
  "complete": false,
  "capped": true
}

The query completed, but the retrieved set did not contain all 247 records available to that query. If a watchlist is applied after retrieval, a matching record outside the retrieved set cannot appear in the output.

There are at least three possible explanations for an empty watchlist result: no matching record in the scanned set, a matching record outside that set, or an unsuccessful or incomplete observation. They do not support the same conclusion.

For this workflow, inspect the health row alongside the matches. Narrowing a date window or adjusting a documented record cap may change coverage, but it is not a guarantee of completeness. A supplier-name match also needs review against the actual product and official recall information. The example is a lesson about bounded retrieval, not a product-safety determination.

Case 2: a missing job needs a healthy comparison

Consider an invented job with ID 101. A failed request that returns no jobs should not mean the same thing as a complete observation of a genuinely empty board.

In the publisher's three-snapshot owner walkthrough, fictional complete inputs produced this sequence:

A failed or incomplete source does not advance that missing count in the documented workflow. Even closed_candidate is a candidate for review; it is not proof that the employer stopped hiring.

For repeated comparisons, use the same source identity and monitor key. When changing from a fictional preset to your own authorized source, start with a new key so the first real observation is not compared against the invented data.

This distinction also matters for product feeds: a truncated catalog export can look like mass product removal. Confirm that the export is complete before interpreting missing identifiers.

Case 3: a successful tender run can report partial coverage

The publisher's public-records guide describes an owner test on 27 October 2026 where the Apify run succeeded, but the result reported OUTPUT.status: partial and coverageComplete: false.

The recorded diagnostics included:

• page_limit_reached
• source_response_size_limit
• record_lookup_limit_reached

Those diagnostics describe the scope of the delivered evidence. The baseline covers the notices returned by that bounded scan, rather than the whole tender market.

A bid team should open the official notice before acting on a deadline or amendment. In a downstream review queue, preserve the current deadline, prior deadline, source link, observation time and coverage diagnostics together. Avoid turning an absent row in a partial collection into a claim that a notice was withdrawn.

A comparison may be valid without being complete research

Some workflows have a different boundary: they compare the exact input you provide.

For example, a two-snapshot catalog comparison can correctly report one added SKU, one removed SKU and one changed SKU. That proves a comparison of those supplied arrays. It does not prove that the upstream exports included every product, or that a removal represents an intentional business action.

In the documented SKU snapshot example, the inputs are fictional. The first export contains 00123 and 00124; the second contains 00123 with a different price and a new 00125. The summary counts are one added, one removed and one changed item.

The useful review questions are:

1. Were the two snapshots meant to cover the same catalog?
2. Are identifiers unique strings, with leading zeros preserved?
3. Did the upstream export finish?
4. Is an empty later snapshot intentional?
5. Where are the full field-level differences stored?

These questions can catch an import-review mistake before someone treats every missing SKU as an approved deletion. A summary row is useful for counting; the full comparison is needed to inspect the affected fields.

Carry the boundary into other evidence workflows

The same review habit applies beyond missing records:

A useful export preserves those boundaries next to the row. If a reviewer must reopen a separate manual to discover that the record is only a candidate, the spreadsheet is easy to overinterpret.

A review process you can use before automating decisions

Start with one decision: which notice needs review, which SKU changed, or which guest issue should be checked first. Choose an input and output that match that decision.

Before running a paid workflow, inspect its accepted inputs, current price and maximum run cost. An empty result does not necessarily mean a free run. Use only sources and exports you are authorized to process.

After collection, check process status, source health and coverage before interpreting changes. If the output is held or partial, preserve that state in the downstream queue. Keep source links and observation times with the evidence, and open the original source before taking consequential action.

The publisher's selection guide covers all 12 existing evidence workflows, including inputs, alternatives, public presets and the limits that matter for each. It can help you decide whether a spreadsheet, direct source, browser audit or hosted comparison fits the work.

No demonstration in this article is a customer result. A completed comparison, a candidate match and a business outcome remain separate facts.