Sichere Projekt-, Liefer- und Launch-Nachweisflaechen werden geladen.
Sichere Projekt-, Liefer- und Launch-Nachweisflaechen werden geladen.
Monatliche Notizen zu Nearshore-Engineering-Teams, CAD- und Dokumentationsqualität, Delivery Controls und QENVEX Launch-Updates.
Operative Subprozessoren
QENVEX nutzt gehostete Anbieter für Application Delivery, Auth, Datenspeicherung, transaktionale E-Mail, CRM-Handoff und Scheduling.
| Provider | Rolle | Datenkontext |
|---|---|---|
| Supabase | Gehostete Datenbank, Authentifizierung, Row-Level Security und serverseitiger Datenzugriff. | Workspace Profile, Leads, Projekte, Tasks, Dateimetadaten, Rechnungen, Support, Notifications, Activity Logs und Auth Records. |
| Cloudflare | Application Delivery, CDN, WAF, Turnstile, Worker Deployment und R2 Object Storage. | Request-Metadaten, Security Signale, gecachte Assets und hochgeladene Dateien, wenn R2 Buckets konfiguriert sind. |
| Resend | Transaktionale E-Mail für Kontaktbestätigungen, interne Alerts, Quote Requests, Newsletter und Workspace Notifications. | E-Mail-Adressen, Namen, Workspace Notification Context, Message Context und transaktionaler Inhalt für Delivery. |
| HubSpot | CRM-Handoff für Leads und zukünftige Commercial Follow-up Workflows. | Lead-Kontaktdaten, Unternehmenskontext, Service Interest, Markt und Form-Metadaten, wenn CRM Sync konfiguriert ist. |
| Cal.com | Scheduling Einstieg für Sales- oder Discovery-Calls, wenn ein Booking Username konfiguriert ist. | Meeting Booking Details, die der Prospect im Scheduling Workflow angibt. |
Diese Seite ist eine operative Transparenzbasis für Provider-Nutzung, Datenkontext und Review-Umfang im Client-Onboarding.
Provider-Nutzung sollte sichtbar, begrenzt und reviewbar bleiben, waehrend die Plattform vom Launch Setup in den Betrieb geht.
Provider-Nutzung bleibt auf Daten beschränkt, die für Auth, Workspace Delivery, Storage, E-Mail, CRM-Handoff, Scheduling und Abuse Prevention nötig sind.
Service-Role Keys, Provider Tokens, Cloudflare Tokens und E-Mail/CRM Credentials bleiben in Server Runtime oder Deployment Secrets.
Provider Settings, Auth Callbacks, R2 Buckets, Worker Bindings, WAF Rules, E-Mail Delivery, CRM Handoff und Live-Smoke-Evidenz muessen im Launch Evidence Package erfasst werden.
Materielle Provider- oder Data-Flow-Aenderungen sollen im Trust Center, in Legal Pages, Subprozessor-Liste und Launch Evidence Package geprueft werden.
Kontaktieren Sie QENVEX für den Provider-Kontext zu Ihrem Engagement.
Kontakt aufnehmen