Shared responsibility

Salesforce API Integration

iDialogue accesses Salesforce through the Salesforce API connection user configured by the Salesforce Admin. That user defines the primary Salesforce permission boundary for agent and server-side workflows. Enabled tools, workflow rules, and approval requirements narrow the available authority further.

Customers should apply least privilege and review:

• OAuth and connected-app policy;
• the integration user's object, field, record, and file access;
• the agents, skills, and tools enabled for each run context;
• the record fields and files selected as input;
• any approval checkpoint before a write or external share; and
• scheduled or background workflows that can run without an active browser session.

Some workflows also include initiating-user or Salesforce page context. External processing should not be assumed to automatically reproduce all row-level sharing and field-level security of the initiating Salesforce user. Customers should verify the configured Salesforce API connection user for each workflow.

File and agent data flow

A typical governed workflow follows the sequence below. Exact processing steps vary by feature and configuration.

sequenceDiagram
    actor User as Salesforce user or automation
    participant SF as Salesforce permissions and Files
    participant ID as iDialogue workflow controls
    participant Agent as Configured agent
    participant Processor as Approved AI or document processor
    participant Records as Dialogue, artifact, and operations records

    User->>SF: Start an approved workflow
    SF->>ID: Send authenticated context and file references
    ID->>ID: Apply customer and workflow controls
    ID->>Agent: Provide approved information and capabilities
    Agent->>Processor: Send task-specific content when required
    Processor-->>Agent: Return task result
    Agent->>Records: Retain only the records required by the workflow
    Agent-->>SF: Propose or perform the permitted outcome
    SF-->>User: Review result and continue the business process

Processor calls, artifact storage, dialogue continuity, operational records, and Salesforce writeback depend on the selected feature, connection user, and workflow configuration.

Customer-facing workflows may also deliver approved documents into an iDialogue Experience or Document Room. A participant can review or sign a document, complete a checklist or form, or upload information. The configured workflow may write approved inputs or outcomes back to Salesforce.

See how agent authority and approvals fit this flow.

Data lifecycle by class

Different categories of data serve different business purposes and have different lifecycle requirements:

Read the public Data Retention Policy and Privacy Policy. Contract terms can add customer-specific commitments.

Tenant isolation

iDialogue associates dialogue history, task inputs, repository artifacts, business outcomes, and operational records with the applicable Salesforce organization. Customer identifiers and access controls keep each organization's information within its authorized scope.

iDialogue does not expose a connected Salesforce org as a general-purpose public query service. Requests must originate through an authenticated or explicitly shared iDialogue surface and are resolved within the applicable organization and workflow context.

For higher-assurance evaluations, detailed architecture, endpoint information, and customer-specific data-flow reviews are available under NDA.

Encryption and transport

iDialogue requires encrypted transport for supported production web and API paths. The platform also uses cloud storage and managed services with encryption capabilities. Exact protocols, keys, storage services, and responsibilities vary by component and customer configuration.

Point-in-time TLS evidence for the multi-tenant API is available in Compliance & Policies. This evidence demonstrates the tested endpoint configuration at the time of review. See the Encryption Policy for documented control objectives.

Connections

iDialogue Connections allow approved workflows to access Salesforce, AI providers, communications platforms, data services, and other external systems. Administrators control which Connections are configured, and agents can use only the Connections exposed through their enabled skills.

Three Connection states are intentionally distinct:

1. Available: a Connection appears in the product catalog.
2. Configured: an administrator has enabled credentials or completed authorization.
3. Used: a particular agent or workflow has an enabled skill that invokes the Connection.

Available does not mean configured, and configured does not mean used.

A Connection appearing in the catalog does not mean customer data is sent to that service. Review the Connections catalog, the customer organization's configured Connections, and the skills enabled for the applicable agent.

Sharing, Rooms, and public publishing

iDialogue supports several distinct delivery and access models:

• Salesforce output returns or attaches a result to the configured Salesforce workflow.
• Invitation-based Rooms or Experiences use member, invitation, token, and session controls for customer-facing access.
• Public publishing deliberately creates content intended for anonymous web access.

Invitation-based Experiences and Document Rooms expose only the content and actions configured for that member and workflow. Room access is not a Salesforce login and does not provide general access to the connected org.

These access models are intentionally distinct. Private Rooms and Experiences use configured membership and access controls, while public publishing is explicitly intended for anonymous web access.

Administrators should review membership, links, domains, expiration, and publication settings before distributing sensitive content, and revoke or archive access when the business purpose ends.

Retention and deletion

Retention is managed by data class rather than through a single universal period. Dialogue history, task inputs, Experience and Room content, repository artifacts, business outcomes, indexed knowledge, operational records, and billing records each have a distinct purpose and lifecycle. See AI & Agent Governance for the corresponding AI-governance explanation.

Deletion requests may involve Salesforce records, iDialogue application state, Experience and Room content, stored artifacts or knowledge, and applicable processing-provider state. Certain records may be retained where required for security investigations, legal obligations, backups, financial records, dispute resolution, or contractual requirements.

Archiving or deleting an Experience may require separate treatment for Room membership, shared documents, customer responses, eSignature records, Salesforce writeback, operational evidence, and protected backups.

See the Data Retention Policy for additional information.

Providers and subprocessors

Pacific Apps, Inc. uses infrastructure and processing providers to operate iDialogue. Provider involvement depends on the feature and workflow being used.

AWS services support core platform hosting and storage. OpenAI is used for configured AI-assisted workflows. Optional Connections involve additional external services only when they are configured and invoked by an approved workflow.

The Third-Party Security Policy describes provider review expectations. The OpenAI Data Processing Addendum summary provides information about the applicable public contractual artifact.

For a current customer-specific provider inventory and data-flow review, contact support@idialogue.app.