Preguntas frecuentes.

The agent runs as a tenant-approved Teams app/bot and authenticates via Azure AD (Entra ID), inheriting your SSO/MFA/Conditional Access policies. Permissions are least-privilege and consent-based (Microsoft Graph + only the connectors you approve). The agent only accesses data sources you authorize and respects existing SharePoint/OneDrive/CRM ACLs—no elevation, no cross-tenant access. All traffic is TLS 1.2/1.3 over HTTPS with no new inbound ports or public endpoints. Conversation context is stored per your retention policy in a tenant-isolated environment; no data is used to train any model, and Zero Data Retention with the LLM provider is available. Full audit logs are captured and can be exported to your SIEM.

The agent follows an outbound-only, cloud-to-cloud communication model. All traffic flows through secure HTTPS/TLS connections to approved Microsoft Graph or Microsoft Azure API Management (APIM) endpoints—there are no inbound ports, VPNs, or direct access to internal networks.When the agent needs to interact with internal business systems (e.g., Dynamics 365, SharePoint, or ERP), those systems expose read-only, least-privilege APIs through your existing APIM layer. This ensures your internal environment remains isolated, with full visibility, throttling, and audit logging managed by your IT controls.

Customers can manage and monitor their agents via the ReshapeX Admin Console, which provides activity logs, KPI tracking, usage metrics and data source management.

Fully on-prem is technically possible but not preferred. We recommend a secure cloud-to-cloud model where all traffic is outbound-only and data stays under your control.

Default (no APIM): Exchange Online → Microsoft Graph → ReshapeX cloud agent. Security is enforced via Azure AD app registrations, Exchange Application Access Policies (scoping to specific shared mailboxes), Conditional Access, IP allowlists, and full audit logs. For events, use either Graph change notifications or delta queries (pull) to avoid inbound webhooks.

Optional - APIM: Insert your APIM between Graph/other systems and the agent to add mTLS, centralized auth, throttling, payload caps, header/payload inspection, and unified logging/policy versioning. Internal apps (Dynamics, SharePoint, ERP) can be exposed read-only, least-privilege through APIM—still no direct access to your internal network.

Why not on-prem: Cloud delivery preserves centralized updates, scale, and continuous patching without expanding your exposure surface. Your data is never used to train models; mailbox content is processed just-in-time, and attachments are indexed into your per-tenant RAG only if explicitly allowlisted.

Data residency can be configured per customer. By default, ReshapeX uses region-specific hosting within AWS, depending on customer preference. Customers may select their preferred geographic region (e.g., U.S., EU, Canada) for data storage and processing.

It doesn't train the LLM; it builds and uses a private RAG index and a lightweight case memory—all under your control.

Scope/control: Only designated mailboxes/folders/labels (e.g., "KB-OK", "Final Quotes") are ingested via Microsoft Graph → your APIM. Nothing else is indexed.

Ingest & extract: Approved emails and attachments (e.g., quote PDFs) are parsed for entities (customer, SKU, terms, SLAs) and chunked/embedded into a per-customer index; ACLs and retention apply.

Draft-time retrieval: When the Outlook add-in is clicked, the agent retrieves similar past replies, approved language, and matching quotes and uses them to draft a response—citing the sources it pulled from.

Human-in-the-loop tuning (no model training): The system learns preferences from usage (which template got sent, edits users keep, tone/sign-off) and updates rules/templates and retrieval boosts.

Sandbox vs prod: Sandbox uses a curated subset (labels/folders you choose) so behavior matches prod without broad exposure; nothing auto-migrates to prod.

Same architecture, tighter guardrails in sandbox. Key deltas:

Scope: Sandbox = one test mailbox + separate AAD app; Prod = approved shared mailboxes per policy.

Permissions: Sandbox = minimum Graph scopes; Prod = least-privilege but may include send/ack scopes as agreed.

Sending: Sandbox = auto-ack OFF (or ON with [TEST] tag + recipient allowlist, external blocked/sinked); Prod = auto-ack per SLA, external sending allowed per policy.

Outlook add-in: Sandbox = deployed to test users only; Prod = org/targeted groups.

Data handling: Sandbox = mail processed transiently, attachment indexing OFF by default; Prod = indexing only for allowlisted sources with retention rules.

APIM policies: Sandbox = stricter rate limits, payload caps, verbose logging; Prod = performance-tuned, version-pinned policies.

Connectivity: Both are outbound-only via Graph → your APIM; Sandbox often uses delta (pull) to avoid webhooks.

Observability: Sandbox = debug/trace on; Prod = standard logging with SIEM export.

Change control: Sandbox = staging for updates/experiments; promote to Prod after security & functional gates.

Cleanup: Sandbox = revoke tokens, delete subs, purge caches/indexes after testing; Prod = steady-state per retention.

An isolated, least-privilege setup that mirrors prod:

Scope: One test shared mailbox + a separate AAD app locked to that mailbox via Exchange Application Access Policy.

Traffic: Outbound-only over TLS; optional delta (pull) instead of webhooks to avoid inbound endpoints.

Behavior: Auto-ack OFF by default (or ON with [TEST] tag + recipient allowlist). Drafts are created via the Outlook add-in; humans review and send.

ReshapeX agents are built using a modular, service-oriented architecture primarily based on Python and TypeScript, with secure REST and GraphQL APIs for communication. Integrations with enterprise systems (e.g., Microsoft 365, Dynamics, Salesforce, SharePoint) use OAuth 2.0, HTTPS/TLS 1.2+, and standardized JSON payloads. The system supports webhooks and message queues (e.g., Azure Service Bus, AWS SQS) where asynchronous processing is needed.

A Microsoft Outlook web add-in (Office.js) surfaces a "ReshapeX" button. On click, the add-in (with AAD SSO and delegated Graph permissions) passes the selected message context to the agent through your APIM. The agent returns a draft (optionally referencing whitelisted SharePoint available PDFs or ERP data); the user reviews/edits and sends. The agent never auto-sends drafts. All traffic is outbound-only from the add-in/tenant to APIM; no internal network exposure.

Only to auto acknowledge the receipt of a customer query. Scoped app registration and Exchange Application Access Policies restrict the agent to specific shared mailboxes. The agent sends receipt confirmations via Graph using send-as or send-on-behalf for that mailbox only.

Guardrails: thread de-duplication (one ack per conversation), external-only, blocklist/allowlist, auto-generated detection, SLA-aware templates, full audit logs.

No. We never send Salesforce credentials or raw CRM records to OpenAI. The only Salesforce-related context we use is:

the cart contents needed to personalize related products, and

the prior conversation history for continuity.

These are stored in our system under our retention policy and are not used to train OpenAI. We access Salesforce via a Connected App using OAuth 2.0 with a dedicated integration user and least-privilege scopes (profile/permission sets), plus optional IP allowlisting and token monitoring/rotation.

Recommended for development/UAT, not strictly required for production. Sandboxes let you validate scopes, profiles/permission sets, and data flows without touching live data; this is Salesforce's own best practice. Production then uses the same approved APIs/permissions you already run.

Recommended for Dev/UAT: use a non-production Dataverse environment (Dynamics sandbox) to validate app registration scopes, security roles, and data flows. Production uses the same approved endpoints/scopes.

Only the minimum textual context needed to answer the current question (e.g., "User asked for lead time on SKU X in their cart"), not tokens, secrets, or full CRM objects. We follow secure-RAG guidance: source whitelisting, query scoping, redaction when applicable, and audit logging.

By default, no. We operate in a no-sync pattern—evaluate eligibility server-side and pass only a minimal flag (e.g., eligible_campaign_ids: ["Q4_WEBINAR"]). If a customer requests performance caching, we can store non-PII derivatives (hashed IDs, campaign flags) with short retention and customer-approved scopes.

Campaign logic runs server-side against Dynamics 365 Dataverse and, if used, Customer Insights (Journeys) segments. The agent's backend (not the LLM) calls Dataverse/CI with a least-privilege Entra ID service principal to read only what's needed (e.g., segment membership, campaign metadata, contact ID). The agent then passes a minimal claim to the LLM (e.g., "eligible for Campaign Q4-WEBINAR")—not raw CRM records.

Dynamics 365 (CRM/ERP) — Contacts, Orders, Cases, Campaigns

Access: Dataverse Web API via Azure AD app registration (service principal) and security roles scoped to the minimal tables/columns needed (contacts, accounts, orders, cases, campaigns).

Use: Personalize responses with known user context (e.g., last order, open case, segment/campaign membership).

Handoff: For live support, the agent escalates to Dynamics 365 Customer Service (Omnichannel); human agents see the transcript and CRM context in the Copilot Service workspace.

All data exchanges between the agent, RAG store, and third-party systems occur via encrypted HTTPS/TLS channels with mutual authentication where supported. No unencrypted communication is permitted. Transport logs and integrity checks ensure that every request/response exchange is verified and auditable.

Yes. You can scope the service principal to read-only roles for specific entities/columns (e.g., allow Contact → contactid, do not allow email/phone).

The LLM never queries data sources directly. It receives derived claims only (e.g., campaign eligibility) from our backend, which enforces ACLs in Dataverse/CI. If the source system denies access, the agent cannot surface the data.

Yes. ReshapeX agents are website-agnostic and will continue to work even if you update or completely rebuild your site. Integration only requires copying six lines of code into the new site, and your agent is instantly live again. Because the agent connects to your backend APIs and indexed data (not to your site's visual layout), changes to design, structure, or CMS do not break functionality.

From a security standpoint, the agent only accesses the data you explicitly allow. We implement safeguards to detect and prevent abuse. The agent does not introduce new attack surfaces or bypass your defenses. All communication runs over encrypted channels (TLS 1.2/1.3), aligned with industry best practices.

Only the minimum textual context required (e.g., "User visited the Conveyor Systems page; they are eligible for Campaign 'October Webinar: Optimizing Material Flow', and the agent can offer a one-click registration link"), not secrets, tokens, or entire CRM records. IDs are resolved server-side via Dataverse/Spryker APIs. Audit logs capture every retrieval and call.

Each customer operates in a logically isolated environment, including separate indexes for RAG, separate encryption keys, and separate access controls. There is no risk of another customer's agent accessing your data.

To date: zero security incidents. ReshapeX is SOC 2 Type II certified, with security at its core: using bidirectional APIs, field-level validation, and automated audit logs. All data remains in your control and is not used to train public models.

The agent respects existing access controls from your systems (Dynamics 365, SharePoint, etc.). If a user does not have access to a document or dataset in the source system, the agent cannot retrieve or display it.

All retrievals, API calls, and authentication events are logged and auditable.

Access is strictly limited. Only your authorized users and designated integration accounts can interact with the agent. ReshapeX employees do not have standing access; any temporary support access requires explicit approval, is time-limited, and is fully logged.

Access is handled through the repository's own API and authentication controls. For SharePoint specifically, we use Microsoft Graph API with Azure AD OAuth 2.0 and a least-privilege app registration. The agent can only access the specific libraries or folders you authorize. Files are indexed into a customer-specific RAG store, never cross-shared, and always stay under your control.

The agent only uses product data that's already public on the vendor's website—including datasheets, pricing, availability/lead times, and product specifications.

Datasheets and configurators: We download these and index them into our retrieval-augmented generation (RAG) system. RAG combines a retrieval engine with a large language model (LLM) to generate accurate, contextual answers.

Pricing and lead times: Since this information changes frequently, the agent does not store it. Instead, it calls the same product/availability APIs the vendor's websites already use, formats the response, and presents it to the user. This process does not expand your exposure surface or create new external endpoints.

We follow secure-RAG guidance: source whitelisting, query scoping, redaction (when applicable), and audit logging.

The agent follows an outbound-only, cloud-to-cloud communication model. All traffic flows through secure HTTPS/TLS connections to approved Microsoft Graph or Microsoft Azure API Management (APIM) endpoints—there are no inbound ports, VPNs, or direct access to internal networks.

When the agent needs to interact with internal business systems (e.g., Dynamics 365, SharePoint, or ERP), those systems expose read-only, least-privilege APIs through your existing APIM layer. This ensures your internal environment remains isolated, with full visibility, throttling, and audit logging managed by your IT controls.

All data in transit is protected using TLS 1.2 or higher, with HSTS enforced at the web application layer. Data at rest is encrypted using AES-256. Authentication follows OAuth 2.0 and OpenID Connect (OIDC) standards, with optional SAML 2.0 integration for single sign-on. Token rotation, IP allowlisting, and multifactor authentication are available for added protection.

PII stays in your Microsoft tenant (Dataverse/Customer Insights/SharePoint). ReshapeX uses read-scoped roles, field-level security, and table-level permissions to limit access. No credentials or raw CRM objects are sent to the LLM; only short, redacted context is used at answer time. All calls are encrypted, audited, and time-boxed to the integration identity.

The agent runs as a tenant-approved Teams app/bot and authenticates via Azure AD (Entra ID), inheriting your SSO/MFA/Conditional Access policies. Permissions are least-privilege and consent-based (Microsoft Graph + only the connectors you approve). The agent only accesses data sources you authorize and respects existing SharePoint/OneDrive/CRM ACLs—no elevation, no cross-tenant access. All traffic is TLS 1.2/1.3 over HTTPS with no new inbound ports or public endpoints. Conversation context is stored per your retention policy in a tenant-isolated environment; no data is used to train any model, and Zero Data Retention with the LLM provider is available. Full audit logs are captured and can be exported to your SIEM.

Yes. We are model-agnostic and apply the same safeguards no matter which LLM provider we use (OpenAI, Anthropic, or others). When connecting via API, we ensure that sharing of input/output data for model training is disabled by default. Both OpenAI and Anthropic's enterprise APIs support this approach, and we configure all deployments so that your data is never repurposed for training. In every case, your information remains under your control and is only used at query time to generate the requested response.

No. The data remains under your control; the model only "reads" it at query time, similar to a secure, dynamic search engine. Nothing leaves your environment. Industry guidance on RAG security stresses source scoping and least privilege, both of which we implement. Sharing of input/output data, evaluation data, and fine-tuning data for training models is disabled in our usage of the OpenAI API.

Your data is siloed, encrypted, and never cross-trained across customers. Agents only use your information for your users. Nothing leaks into public models.

Each customer operates in a logically isolated environment, including separate indexes for RAG, separate encryption keys, and separate access controls. There is no risk of another customer's agent accessing your data.

Yes. We are model-agnostic and apply the same safeguards no matter which LLM provider we use (OpenAI, Anthropic, or others). When connecting via API, we ensure that sharing of input/output data for model training is disabled by default. Both OpenAI and Anthropic's enterprise APIs support this approach, and we configure all deployments so that your data is never repurposed for training. In every case, your information remains under your control and is only used at query time to generate the requested response.

No. The data remains under your control; the model only "reads" it at query time, similar to a secure, dynamic search engine. Nothing leaves your environment. Industry guidance on RAG security stresses source scoping and least privilege, both of which we implement. Sharing of input/output data, evaluation data, and fine-tuning data for training models is disabled in our usage of the OpenAI API.