sarah_bioni
ServiceNow Employee

When configuring a custom feed (e.g., a REST-based integration that ingests indicators/observables into TISC table), the run fails with an error similar to:

Encountered error running the integration. 
Error: The Data source response processor only supports sys_attachments

You might also see:

  • A long execution time followed by failure in the MID flow/Scripted REST step
  • No attachment created on the target record
  • Empty or missing attachment reference in the post‑processing step

🔎 Root Cause

For many TISC ingest patterns, ServiceNow stores the raw response payload from your feed as a sys_attachment on a target record (often a staging/ingest table).
If the user account running the integration (typically the MID Server credential or connection & credential alias user) doesn’t have create/write permissions on the target table record that will hold the attachment, the platform cannot create the sys_attachment. The response processor therefore fails with the message that it “only supports sys_attachments.”

In short: the integration expects to save your REST response as an attachment on a record, but the executing user isn’t allowed to create that attachment because they lack create/write access on the target table.


Solution (Least‑privilege, not admin)

Do not grant admin.
Grant your MID Server / integration user only the minimum roles required to:

  1. Create records (if the pipeline inserts a staging/ingest record).
  2. Write to those records (to associate the attachment).
  3. Read those records (for verification and post‑processing).
  4. Allow creation of sys_attachment linked to that record (this is governed by the target record’s ACLs; you typically do not need direct sys_attachment ACLs if the record write is allowed and the out‑of‑box attachment ACLs reference the parent record).

Regards,

Sarah Bioni Nascimento

Version history
Last update:
yesterday
Updated by:
Contributors