← Home

Security & Data Handling

Sylo — Security & Data Handling

This document describes how Sylo managed packages handle data and security, for AppExchange Security Review, customer questionnaires, and assurance. It covers Sylo Base (shared dependency) and the products that depend on it: Sylo Rollups, Sylo Scheduler, and Sylo Lookup. Sylo Connect (Jira integration) is summarized separately because it includes external callouts.

Suite overview

Sylo products run inside the customer’s Salesforce org. Configuration is stored primarily in Custom Metadata and standard Salesforce features (permission sets, sharing, FLS). Except where noted below, customer business data is not transmitted to Sylo or other publisher systems—processing stays in the org.

Install only the packages you use. Sylo Base is required by Rollups, Scheduler, and Lookup as declared in each package’s dependencies.

Sylo Base

Purpose: Shared Apex utilities, Lightning components, and helpers used by other Sylo packages (e.g. metadata describe, filter building, session-based access to the same org’s Salesforce APIs).

Data: No standalone business data store. Does not send customer record data to external servers.

External access: Helpers may perform callouts only to the same Salesforce org (e.g. My Domain) when a product uses them for Tooling/REST operations; those products document Remote Site Settings requirements.

Authorization: Access to Base-only surfaces is indirect through the hosting product’s permission sets and apps.

Sylo Rollups

Declarative rollup summaries from child records onto parent records.

Data processed

  • Custom Metadata (Rollup_Definition__mdt) — Rollup definitions (objects, fields, filters, calculation mode). Org-specific; writable by admins with Sylo Rollups Admin and appropriate metadata permissions.

  • Standard and custom objects — Reads aggregates from objects the running user can access; writes only configured target fields on parents. Sharing and FLS apply; execution uses the triggering or scheduled user context.

  • Package custom objects — Rollup_Log__c, Rollup_Audit__c, Rollup_Queue__c, Rollup_Removed_Object__c for logs, audit, scheduled queue, and object-support removals. No external replication.

Data not sent off-platform (Rollups)

  • No customer PII or analytics are sent to the publisher.
  • Outbound HTTP is limited to the same org’s Salesforce API (My Domain) for Tooling operations (trigger deploy, field creation, deploy status), after the admin adds that URL to Remote Site Settings.

Authentication & authorization (Rollups)

  • Authentication: Salesforce session only (Lightning/API).
  • Authorization: Sylo Rollups Admin permission set and app assignment; batch/trigger/flow run as the relevant Salesforce user; metadata updates require Customize Application (or equivalent) plus permissions.

External integrations (Rollups)

  • Salesforce REST/Tooling (same org) — As above. No third-party SaaS required for core rollup behavior.

Encryption, security practices, compliance (Rollups)

  • Subject to the customer org’s Salesforce encryption and transport security.
  • Apex controllers use with sharing where applicable; LWCs follow standard Lightning security.
  • Depends on Sylo Base only (no other managed package required for Rollups itself).
  • Not designed for special PCI/HIPAA processing; customers classify their own data.

Sylo Scheduler

Orchestrates Apex jobs from Custom Metadata (cron, groups, dependencies, logs).

Data processed

  • Custom Metadata (Scheduler_Definition__mdt) — Job definitions (Apex class, cron, dependencies, etc.).
  • Package object Scheduler_Log__c — Execution history.
  • Salesforce CronTrigger / async — Standard platform scheduling; no separate publisher datastore.

External systems

  • None for core scheduling. Jobs run your org’s Apex (Schedulable / Batchable) per definition.

Authentication & authorization

  • Sylo Scheduler Admin permission set; operations respect the running user and org rules for the Apex classes you configure.

Sylo Lookup

Auto-populates lookup fields by matching source records to targets (multiple match modes, filters, execution modes).

Data processed

  • Custom Metadata (Lookup_Definition__mdt, related CMT) — Rule definitions, optional reusable filters, object support.
  • Standard/custom objects — Reads/writes per rule and user access; sharing/FLS apply.
  • Package objects — e.g. Lookup_Log__c, Lookup_Audit__c, Lookup_Removed_Object__c, settings. No external replication of business data.

External systems

  • Same pattern as Rollups for Tooling/trigger deployment: callouts to the same org’s My Domain URL when admins use in-app deploy; Remote Site Settings required for those features.
  • Licensing: May use Salesforce Feature Management / package license checks for tier limits (no customer record payload to publisher beyond platform licensing APIs as defined by Salesforce).

Authentication & authorization

  • Sylo Lookup Admin permission set; Flow invocable and batch/trigger contexts use defined Salesforce execution users.

Sylo Connect (Jira)

Summary for reviewers: Sylo Connect synchronizes data between Salesforce and Atlassian Jira using admin-configured connections.

Data processed

  • Custom Metadata — Integrations, field mappings, connection metadata (base URL, auth type; secrets stored in protected custom objects, not in LWC).
  • Custom objects — e.g. credentials (tokens/secrets), sync state, logs. Record data subject to configured mappings may be sent to Jira and received from Jira per integration rules.
  • Callouts — HTTPS to Jira/Atlassian endpoints (customer’s Jira instance or Atlassian cloud APIs). Remote Site / Named Credential style configuration as implemented in the package.
  • Inbound webhooks — Jira posts to a Salesforce REST endpoint (@RestResource); admins expose the URL via Experience Cloud / Site as documented in the product.

Authentication

  • API tokens, OAuth tokens, and related secrets stored in Salesforce custom objects; Apex performs callouts; tokens are not exposed to LWCs beyond what’s required for OAuth UX.

If Connect is not installed, none of this applies.

Encryption (all products)

Data is protected by Salesforce platform encryption and TLS in transit. Sylo packages do not replace org-level encryption. Customers remain responsible for classification and compliance.

Reporting security issues

Contact the publisher via the AppExchange listing or support URL published by the vendor. Do not disclose vulnerabilities in public forums.

Update this document when data flows, integrations, or package boundaries change.