C
CONXA

Legal

Data Processing

Plain-language explanation of customer and CONXA data roles, subprocessors, local-only data, deletion requests, and enterprise DPA expectations.

Updated June 11, 202610 min read

Summary

  • Customers usually control the workflows they record, publish, and distribute.
  • CONXA processes account, workspace, package, billing, telemetry, support, and compile-time data to provide the service.
  • A signed data processing addendum should control enterprise-specific roles, subprocessors, transfers, audits, and retention.

Data roles

In many business use cases, the customer decides what workflows to record, what target application is used, who receives the installer, and what data is processed during execution. For that customer-controlled workflow data, the customer is typically the primary decision-maker.

CONXA makes independent decisions for account administration, billing records, fraud prevention, service security, product analytics, support operations, and legal compliance. For those areas, CONXA may act as an independent controller or equivalent role depending on applicable law.

Processing activities

ActivityData involvedPurpose
Account accessUser identity, workspace role, session metadata.Authenticate users and secure dashboard access.
CompilationWorkflow metadata, screenshots, DOM-derived context, validation intent, logs.Create and repair skill packages requested by the customer.
Package hostingSkill package content, plugin slug, package versions, installer metadata.Distribute package updates and hosted installers.
TelemetryRun status, timing, skill version, compact error and recovery information.Show product health and support reliability improvements.
BillingPlan, payment provider IDs, usage meters, billing periods.Operate subscriptions and enforce plan limits.

Subprocessors and service providers

CONXA may use subprocessors or service providers for hosting, identity, payments, email, support, logging, security, and LLM infrastructure. Examples in the current product include Clerk-style identity services and Razorpay-style checkout services.

Enterprise customers that require a named subprocessor list, notice period, audit terms, cross-border transfer terms, or region-specific controls should capture those requirements in a signed data processing addendum.

Local-only data

Target-application browser sessions are not normal cloud processing inputs. They are local Build Studio or runtime state. Published package output should exclude auth files and browser storage state.

If a customer voluntarily sends logs, screenshots, or files to support, those materials become support data and may be processed for troubleshooting.

Access, deletion, and return

Customers can request access, export, correction, deletion, or return of customer-controlled data through support or through product controls where available. CONXA may retain data where needed for billing, security, legal obligations, backups, dispute resolution, or abuse prevention.

End users whose data belongs to a customer workspace may need to contact that customer first. CONXA may route requests to the workspace owner when the customer controls the relevant data.

Enterprise DPA

This page is a public explanation, not a full enterprise data processing addendum. Enterprise customers should use a signed DPA to define controller/processor roles, subprocessors, breach notice, audit rights, retention, cross-border transfers, security exhibits, and deletion assistance.

Drafting references

These public resources informed the policy structure. They are not a substitute for legal review.

Related docs