Skip to main content

Troubleshooting

Common problems and what to do about them.

The workflow will not publish​

A workflow must validate before it can be published. The editor shows what is wrong; the usual causes are:

  • A required parameter is empty. Check every node's configuration panel — required fields are marked, and a node that needs a connection will not validate without one.
  • Two nodes are connected but incompatible. The output type of one cannot feed the input of the other. See the compatibility table. The most common case is connecting an upload straight to a processing node without a reader in between.
  • Part of the graph is disconnected. A node or group of nodes with no path to the rest of the workflow will never run.

Nothing happens when I trigger it​

  • Is the workflow published? Drafts cannot be triggered, and a draft's upload page is not live.
  • Was it stopped? A stopped workflow accepts no new runs.
  • Are you triggering the right version? Editing a published workflow creates a new version. Check that the version you expect is the published one.
  • For database polling: checks run on a five-minute interval, so even immediately is not instant. Also confirm the Processing Mode — New Entries Only ignores everything that existed before the workflow was created.

The run failed at the first node​

Almost always the file, or how it is being read.

  • Reader version mismatch. Read CycloneDX and Read SPDX are configured with an expected version. A 1.6 file fed to a reader expecting 1.3 will not parse. Check what your generator actually emits.
  • Wrong reader. A CycloneDX file will not go through Read SPDX.
  • Not actually an SBOM. Confirm the uploaded file is what you think it is.

The run failed at a node that used to work​

Start with the connection that node uses.

Open Connections and check its status. Error means the last attempt failed — usually changed credentials, expired access, or an unreachable host. Workbench connections can be checked directly by running a node with the test-connection command.

The run is stuck in progress​

A run that has sat in progress far longer than usual, with a node that never finishes, is not something you can resolve from the interface. Note the workflow, the execution, and which node is stuck, and contact your administrator or FossID support.

Note that a run showing pending approval is not stuck — it is waiting for a person. See Reviews.

The results are not what I expected​

The compliance report flags things that are present​

Check the order of your nodes. Regulatory Compliance reports on the SBOM as it is at that point in the pipeline, so running it before the steps that enrich or correct the data means it sees the raw supplier version and reports gaps your own workflow was about to fill. Move it later.

If the SBOM is genuinely inconsistent between suppliers, adding Normalize Data after the reader will reconcile component identifiers before the check runs.

Normalization changed more than expected​

That is what it does — and it records every change. Turn on Include notes and comments in Generate PDF Report to see exactly what was rewritten. Original values are always preserved.

To narrow its scope, reduce Normalize Fields to only the dimensions you want canonicalized, or set Mode to structural-only to stop it consulting the Knowledge Base at all.

A merge produced duplicates​

The Dedup Key decides when two entries are the same component. The default, purl, cannot match components that have no purl. If your inputs lack them, try name-and-version. Conversely, purl-and-hash is stricter and will keep entries whose checksums differ.

An exported SBOM does not match the original​

Expected. Conversion is faithful in content but not byte-for-byte — identifiers are rewritten, structure is rebuilt, and targeting an older specification version drops newer fields. See what to expect from a round trip.

The execution's files are gone​

Execution files are retained for a limited period and then removed. For results that need to persist, add a Database Update or Send Email Report node so the workflow delivers them somewhere permanent, rather than relying on the execution's own storage.

A reviewer did not receive their email​

  • Check the address on the Review node.
  • Have them check their spam folder — the email carries an attachment and a one-time link.
  • Confirm the execution actually reached the review node: it should be at pending approval.

Getting help​

When contacting support, include the workflow name and version, the execution, which node is involved, and the statuses shown. That is usually enough to identify the problem without further back and forth.