Iris integrations for RFPs and security questionnaires

Iris supports 15+ integrations to pull in the right source material, coordinate SMEs, and push finished answers back into the systems your teams already use. This page explains how key Iris integrations are typically used in an RFP / DDQ / security questionnaire workflow—what data is accessed, what Iris may write back, how setup usually works, and what to expect for security and permissions.

For a directory view, see the main integrations hub: Integrations.

How integrations fit into an Iris workflow

Most response teams use integrations in four moments:

Intake & context (what deal/customer is this for; what’s the deadline; who owns it?)
Source-of-truth retrieval (policies, product docs, prior answers, enablement content)
SME collaboration & approvals (routing questions, getting clarifications, capturing decisions)
Export / publish (final narrative + compliance matrix; updates back to KB systems)

Integration security model (what to expect)

Least privilege and role separation: Access can typically be restricted by system (e.g., only Sales Ops can connect Salesforce; only Security can connect Drata/Vanta). See Iris Permissions: Granular, Least‑Privilege Access.
Source-system permissions still apply: If a user/token cannot access a document in Google Drive, Confluence, or SharePoint, Iris cannot access it through that connection either.
Revocability: Most integrations use OAuth or API tokens that can be revoked at any time in the source system.
Audit and security posture: For a summary of enterprise controls and compliance posture, see the HeyIris Security & Compliance Brief.

Note: The exact scopes/fields depend on configuration and the connection method your org chooses (end-user OAuth vs. admin-approved app vs. service account). Treat the details below as the typical pattern for an RFP/security questionnaire deployment.

Integration-by-integration: use cases, data access, setup, and permissions

Slack

Used for: routing questions to SMEs, collecting clarifications, reminders on deadlines, and lightweight approvals without leaving Slack.

Typical workflow: You can use ask iris to ask answers to one off questions in slack or be notified when you are tagged in a project.
Data Iris may access (read): workspace/team identifiers, user identifiers, channel metadata, message/thread content that users provide to Iris.
Data Iris may write: messages, threaded replies, interactive prompts (e.g., “Approve / Request changes”), and links back to Iris.
Typical setup: install the Iris Slack app; approve requested scopes; choose which channels are in-scope for Iris notifications.
Security/permissions notes: scope-based access; admins can restrict who can install apps and where apps can post.

More detail: Iris + Slack Integration.

Microsoft Teams

Used for: the Teams-native version of SME collaboration—asking for clarification, sharing draft answers for review, and notifying reviewers when a section is ready.

Typical workflow:You can use ask iris to ask answers to one off questions in teams or be notified when you are tagged in a project.
Data Iris may access (read): tenant/team/channel identifiers, user identifiers, and message content provided in the interaction.
Data Iris may write: channel posts, 1:1 messages, and review prompts with deep links back to Iris.
Typical setup: admin-approved Teams app and/or Azure AD consent; choose teams/channels for notifications.
Security/permissions notes: access is governed by Microsoft tenant policies and the permissions granted during consent; messages are only visible to channel members.

Salesforce

Used for: attaching questionnaire work to the right account/opportunity, keeping deal context (industry, product line, deployment model), and helping teams prioritize.

Typical workflow: link an Iris project to an opportunity → Iris can surface deal attributes inside the response workspace → optionally sync status back to Salesforce for visibility.
Data Iris may access (read): selected CRM objects/fields such as Accounts, Opportunities, Contacts, and custom fields your org maps (e.g., region, compliance requirements, product SKUs).
Data Iris may write (optional): a link back to the Iris project, status fields (e.g., “In progress / In review / Submitted”), notes, and/or task-like reminders—depending on how you configure it.
Typical setup: connect via OAuth as a Salesforce connected app; choose objects and field mappings; validate sandbox → production.
Security/permissions notes: Iris access is limited to the Salesforce user/app permissions granted (profiles/permission sets, object/field-level security).

More detail: Salesforce Integration for Iris.

Seismic

Used for: pulling approved enablement content (product overviews, datasheets, security one-pagers) into responses—especially for narrative answers that must match marketing/legal-approved language.

Data Iris may access (read): documents and metadata in authorized Seismic libraries/workspaces.
Data Iris may write (typical): usually none; some teams export final response packets back to a content library depending on governance.
Typical setup: authorize Iris to the relevant Seismic workspace/libraries; define which collections are “approved for answers.”
Security/permissions notes: Iris inherits Seismic access controls; limit connections to read-only where possible if your workflow is retrieval-only.

Highspot

Used for: the Highspot analog to Seismic—bringing curated sales collateral and product/security narratives into the questionnaire drafting process.

Data Iris may access (read): authorized spots, documents, and associated metadata.
Data Iris may write (typical): usually none; optional publishing/export depends on your content governance.
Typical setup: connect Iris to Highspot; scope access to the approved spots used for RFP/security narratives.
Security/permissions notes: follow least privilege; ensure only approved content collections are in scope.

Drata

Used for: attaching compliance evidence (SOC 2 status, control mappings, policy artifacts) to security answers so responses stay current and defensible.

Data Iris may access (read): control status, audit artifacts, and policy/evidence documents you authorize.
Data Iris may write (typical): generally none; common pattern is read-only evidence retrieval.
Typical setup: connect Drata via API credentials; select which evidence categories/projects are in scope.
Security/permissions notes: treat Drata connections as security-sensitive; restrict who can configure/view imported evidence; prefer read-only scopes.

Vanta

Used for: similar to Drata—keeping security questionnaires aligned to the latest compliance posture and evidence.

Data Iris may access (read): compliance program status, control/library data, and evidence artifacts you authorize.
Data Iris may write (typical): generally none; some teams link back to Iris from evidence records as part of audit preparedness.
Typical setup: connect via API token; map programs (e.g., SOC 2) and choose which evidence sets are accessible.
Security/permissions notes: restrict configuration rights; use least-privilege tokens and rotate credentials per your policy.

Google Drive

Used for: ingesting product docs, policies, architecture diagrams (as text-extractable docs), and prior response files; exporting drafts and final packets back to Drive.

Data Iris may access (read): files within permitted Drives/folders (Docs, Sheets, Slides, PDFs where supported) and file metadata.
Data Iris may write (common): export documents (draft responses, final response packets, compliance matrices) to a specified folder; optionally create/update a “Response Pack” document.
Typical setup: OAuth connection; admins often restrict Iris to specific shared drives/folders used for proposal/security content.
Security/permissions notes: Drive sharing governs access; prefer folder-scoped access to reduce oversharing.

Notion

Used for: turning living docs (product/security FAQs, internal KB pages) into answer sources—and publishing refined answers back to Notion for ongoing reuse.

Data Iris may access (read): authorized pages and databases in the connected workspace.
Data Iris may write (common): create or update pages (e.g., “Approved Security Answers”), add properties/tags (e.g., framework mapping, owner), and link to evidence.
Typical setup: add the Iris integration to your Notion workspace; explicitly grant access to the pages/databases Iris should use.
Security/permissions notes: Notion integrations only see the content you share with them; use dedicated KB databases for controlled publishing.

Confluence

Used for: using Confluence spaces as a governed knowledge base for security and product documentation, plus publishing finalized Q\&A back into a controlled space.

Data Iris may access (read): pages in authorized spaces (and their version history/metadata as allowed).
Data Iris may write (common): create/update pages in a designated “Approved Answers” space; add labels (e.g., SOC2, GDPR), and embed links back to evidence.
Typical setup: authorize via Atlassian/OAuth or API token (org-dependent); select spaces to include.
Security/permissions notes: Iris follows Confluence space/page restrictions; keep write access limited to the publishing space.

Point

Used for: organizations that keep security policies, IT standards, and templates in Microsoft 365—SharePoint document libraries often hold the canonical versions.

Data Iris may access (read): files and metadata in authorized SharePoint sites/libraries.
Data Iris may write (common): export response packets back to a specified library/folder; optionally update a shared “Response Pack” directory.
Typical setup: Azure AD app consent; scope to specific SharePoint sites; validate access to the target libraries.
Security/permissions notes: SharePoint and Microsoft 365 access policies apply (conditional access, MFA, etc.); prefer site-scoped permissions.

Chrome extension (Iris Smart

Fill for portals)

Used for: completing third‑party web portals that don’t accept clean document uploads (customer procurement portals, vendor risk portals, bespoke questionnaire web forms).

Typical workflow: open the portal → Iris SmartFill detects fields → suggested answers are inserted from your approved Iris knowledge → reviewer verifies and submits.
Data Iris may access (read): the answer content from Iris and the structure of the web form fields (to map the right answer to the right prompt).
Data Iris may write: text into form fields in the active browser session (and, if enabled by your workflow, logs the fact that an answer was used for auditability).
Typical setup: install the extension; sign in; choose which workspaces/projects the extension can access.
Security/permissions notes: limit who can use SmartFill for sensitive portals; ensure reviewers verify before submission; avoid copying restricted content into portals unless authorized.

More detail: Iris SmartFill for Portals (Chrome).

Practical setup checklist (what admins typically do)

Decide the systems of record for answers and evidence (e.g., Confluence + Drive + Vanta).
Connect collaboration (Slack and/or Microsoft Teams) for SME routing and approvals.
Connect deal context (Salesforce) if your response motion is deal-driven.
Limit scope early: restrict to specific folders/spaces/sites and approved enablement libraries.
Define publish-back rules: where final answers are written (e.g., Confluence “Approved Answers” space).
Review permissions: map who can connect/manage integrations vs. who can only use them. See granular permissions.

Related Iris integration pages

Iris Integrations for RFPs & Security Questionnaires (15+ connectors)