- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
yesterday
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:
- Create records (if the pipeline inserts a staging/ingest record).
- Write to those records (to associate the attachment).
- Read those records (for verification and post‑processing).
- Allow creation of
sys_attachmentlinked to that record (this is governed by the target record’s ACLs; you typically do not need directsys_attachmentACLs if the record write is allowed and the out‑of‑box attachment ACLs reference the parent record).
Regards,
Sarah Bioni Nascimento
