> ## Documentation Index
> Fetch the complete documentation index at: https://support.entegrata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Emitters Overview

> How Entegrata writes data back out to external destination systems

## What is an Emitter?

An **emitter** is the mirror of a [connector](/data/collector/data-connectors/overview): where a connector brings data **in** to the Lakehouse, an emitter pushes selected data **out** to an external system you control (your SQL Server, your Fabric Warehouse, etc.).

Emitters use the same *integration types* the collector uses (Microsoft SQL Server, Microsoft Fabric SQL, and so on) — but each emitter requires its own [connection](/data/collector/connections/overview) to the destination system, separate from any collector connection. Emission connections need **write** credentials; collection connections only need **read**. You can't reuse a collector connection for an emitter, even if it points at the same system.

<Card title="Browse all destinations" icon="paper-plane" href="/data/collector/data-emitters/catalog">
  See which systems Entegrata can emit to today
</Card>

## How an Emitter Works

Each emitter is bound to one **destination connection** and one **source layer** in the Lakehouse:

* **Source layer** — typically the curated Silver layer of a pipeline you've already mapped. Emit takes whatever transformations you've defined in the pipeline and ships the result.
* **Destination connection** — the credentials and network details for the system on the receiving end.
* **Resource selection** — the specific tables/views from the source layer the emitter is allowed to write.

On every emission run, Entegrata:

<Steps>
  <Step title="Read from the source layer">
    Loads the latest contents of each selected resource from the Lakehouse.
  </Step>

  <Step title="Stage and apply">
    Writes rows into a staging table in the destination, then atomically swaps or merges into the target. Existing indexes, unique keys, and foreign keys are preserved across the swap.
  </Step>

  <Step title="Record the result">
    Logs which entities succeeded, which failed, row counts, and duration.
  </Step>
</Steps>

## Emitter Properties

Every emitter has a set of properties you configure when you create it. Some apply to all destinations; others are specific to the destination type the emitter targets.

### Core Properties

<ResponseField name="Name" type="string" required>
  Display label for the emitter. Used everywhere the emitter appears in the admin portal.
</ResponseField>

<ResponseField name="Description" type="string">
  Optional human-readable description.
</ResponseField>

<ResponseField name="Connection" type="string" required>
  The destination [connection](/data/collector/connections/overview) this emitter writes to. Only active emission connections are selectable.
</ResponseField>

<ResponseField name="Trigger Type" type="enum">
  How emissions are kicked off.

  * **Manual** — run on demand from the emitter detail page.
  * **Event** — currently fires automatically when an associated pipeline run completes. More event sources may be added in the future.

  <Note>
    Event-driven emitters can still be triggered manually at any time from the emitter detail page — the trigger type controls automatic runs, not whether you're allowed to run it yourself.
  </Note>
</ResponseField>

<ResponseField name="Use Sys ID" type="boolean" default="true">
  Swap primary-key and foreign-key columns to a numeric `sys_id` (bigint) instead of the default `id` (uuid) when the source resource has one. Use this when the destination prefers integer keys for indexing or downstream tooling.
</ResponseField>

### Destination-Specific Properties

Beyond the core fields, each emitter exposes options that come from the destination type. These are shown on the **Options** tab when you create or edit an emitter, and the available fields are determined by the selected connection.

<ResponseField name="Catalog" type="enum">
  Which Lakehouse layer the emitter pulls from. Currently only **Silver** is supported. **Gold** may be enabled as a source in the future.
</ResponseField>

<ResponseField name="Target Schema" type="string">
  Schema inside the destination database where emitted tables land. Defaults vary by destination (`dbo` for SQL Server / Fabric, etc.). Dedicate a schema to Entegrata — see [Permissions Model](#permissions-model) below.
</ResponseField>

<ResponseField name="Naming Convention" type="enum" default="snake_case">
  How emitted table and column names are formatted. Default is `snake_case`. Configure to match the downstream tools that consume the replica.
</ResponseField>

<Note>
  The exact set of destination-specific properties depends on the connector type. See the per-destination guide ([Microsoft SQL Server](/data/collector/data-emitters/mssql), [Fabric SQL](/data/collector/data-emitters/fabric-sql), [Fabric Warehouse](/data/collector/data-emitters/fabric-warehouse)) for the full list available for that destination.
</Note>

## Emission Modes

You choose the mode when you start an emission. Entegrata then makes a best-effort attempt to achieve that mode and falls back automatically if the underlying data doesn't allow it.

<Tabs>
  <Tab title="Full">
    Emit every selected resource from scratch. Entegrata loads all rows into staging tables and atomically swaps them with the targets.

    Use Full when you want a guaranteed clean state in the destination, after large schema changes, or for the first run.
  </Tab>

  <Tab title="Incremental">
    Emit only what has changed in the source layer since the last successful emission, applying inserts, updates, and deletes via a `MERGE` against the target's primary key.

    <Note>
      If a source table has been rebuilt or changed dramatically enough that an incremental merge would no longer be performant, Entegrata automatically falls back to Full for that table. The mode you selected is honored where possible — affected tables are upgraded to Full transparently.
    </Note>
  </Tab>

  <Tab title="Specific">
    Emit only a curated subset of resources you pick from the catalog. Useful for backfilling a single table, isolating a problem table, or shipping a fresh dataset without re-running everything.

    Entegrata automatically pulls in any tables your selection depends on via foreign keys, so referential integrity is preserved on the destination.
  </Tab>
</Tabs>

## Lifecycle

<Steps>
  <Step title="Create an emission connection">
    Add the destination's credentials and network details. This is a **separate connection** from any collector connection pointing at the same system — emission connections need write access.
  </Step>

  <Step title="Create an emitter">
    Bind a source pipeline layer to the destination connection. The emitter inherits credentials and network rules from the connection.
  </Step>

  <Step title="Pick resources">
    Choose the tables/views to emit. The picker surfaces row counts, recently-updated flags, and foreign-key dependencies so you can see what will be included.
  </Step>

  <Step title="Run the emission">
    Trigger the emitter on demand or let it run on its configured schedule, picking Full, Incremental, or Specific.
  </Step>

  <Step title="Monitor">
    Check the emitter detail page to see per-run status, per-entity outcomes, and row counts.
  </Step>
</Steps>

## Permissions Model

Emitters need **write** access to the destination, unlike collectors which only need read. The service account or identity the emission connection uses typically needs:

* `SELECT`, `INSERT`, `UPDATE`, `DELETE` on the target schema
* `CREATE TABLE`, `ALTER`, `DROP` on the target schema (so Entegrata can create staging tables, apply schema changes, and atomically swap tables on Full)
* `VIEW DEFINITION` on existing objects in the schema

<Warning>
  Entegrata manages the lifecycle of the tables it emits — it creates, drops, and swaps them as part of normal operation. Dedicate an emission schema rather than sharing one with tables maintained by other systems.
</Warning>

The exact permissions vary by destination. See the per-destination guide for specifics.

## Supported Destinations

<CardGroup cols={2}>
  <Card title="Microsoft SQL Server" icon="database" href="/data/collector/data-emitters/mssql">
    On-prem SQL Server, Azure SQL Database, Azure SQL Managed Instance, or RDS for SQL Server
  </Card>

  <Card title="Microsoft Fabric SQL" icon="cloud" href="/data/collector/data-emitters/fabric-sql">
    Microsoft Fabric SQL endpoint
  </Card>

  <Card title="Microsoft Fabric Warehouse" icon="warehouse" href="/data/collector/data-emitters/fabric-warehouse">
    Microsoft Fabric Warehouse
  </Card>
</CardGroup>

<Tip>
  Don't see your destination? Contact your Entegrata Customer Experience Manager about adding emit support to an existing connector or building a new one.
</Tip>

## Related

<CardGroup cols={2}>
  <Card title="Connector Catalog" icon="plug" href="/data/collector/data-connectors/overview">
    Browse the systems Entegrata can collect data from
  </Card>

  <Card title="Connections" icon="link" href="/data/collector/connections/overview">
    Manage the connections emitters depend on
  </Card>

  <Card title="Pipelines" icon="pipe-valve" href="/data/pipeline/overview">
    Define the transformations whose output emitters ship
  </Card>

  <Card title="Jobs" icon="clock" href="/data/collector/jobs/overview">
    Monitor emission runs alongside collection runs
  </Card>
</CardGroup>