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