> For the complete documentation index, see [llms.txt](https://documentation.astera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.astera.com/project-management-and-scheduling/events/system-events.md).

# System Events

In this document, you'll build a complete system event solution end to end: you'll subscribe to a built-in platform event and react to it.

### Use Case

We want to keep an audit log: every time a database table is created during a job, capture the details to a file. We'll subscribe to the built-in `DatabaseTableCreated` event.

Because the event is predefined and raised automatically, a system event solution has just two parts:

1. **The event source**: an operation that raises the system event, here a *Database Destination* that creates a table. You don't add any event object to it.
2. **A subscriber flow**: a separate flow with an *Event Subscription* object that listens for the event.

### Step 1: The Event Source

System events fire as a side-effect of the operation that produces them. For `DatabaseTableCreated`, that operation is a *Database Destination* creating a table.

* When a *Database Destination* has **Create/Replace Table** enabled, running the flow raises `DatabaseTableCreated` automatically. It also raises `DatabaseTableDropped`, because **Create/Replace Table** drops the existing table before recreating it.

  <figure><img src="/files/la1gK3uIdcLHcn2guw44" alt=""><figcaption><p>01-system-event-database-table-created</p></figcaption></figure>

There is no *Raise Event* object and nothing else to configure on this side. Enabling the operation is all that's required.

### Step 2: Subscribe to the Event

The subscriber is a separate flow that begins with an *Event Subscription* object, its source.

1. Create a new flow and add an *Event Subscription* object as its source.

   <figure><img src="/files/6kUF0kCUfCss6xYY4yVj" alt=""><figcaption><p>02-system-event-subscriber-flow</p></figcaption></figure>
2. Select the *System Event* to subscribe to `DatabaseTableCreated`.<br>

   <figure><img src="/files/iDv56EbXI3oN5zg7yW5S" alt=""><figcaption><p>03-system-event-subscription-configuration</p></figcaption></figure>
3. The event's payload appears under the **EventData** node. **Map** the fields (`TableName`, `SchemaName`, `DatabaseName`, `ServerName`, `ActionName`) to a *Delimited (CSV) Destination*.
4. To react only to a specific table, add a **match value**. For example, set `TableName = Orders` so the subscriber runs only when that table is created, ignoring all others.<br>

   <figure><img src="/files/T44tTqIv30qb3gdvf6cK" alt=""><figcaption><p>04-system-event-subcscriber-match-value</p></figcaption></figure>

{% hint style="info" %}
**Note**: Match values are set per payload field. Set them on multiple fields and **all** must match; set none and the subscriber runs every time. Matching is not case-sensitive and ignores surrounding spaces.
{% endhint %}

### Step 3: Run or Publish

* **While testing**, run the flow that creates the table as part of your project; the subscriber in the same project runs automatically.
* **For ongoing auditing**, so the subscriber logs table creations from any deployed flow, **publish** it to the server.

  <figure><img src="/files/A8yN3GZFiGah0JnIsfkL" alt=""><figcaption><p>05-publish-to-catalog</p></figcaption></figure>

See [How Events Are Delivered](/project-management-and-scheduling/events.md#how-events-are-delivered) for local vs. published subscribers.

### Available System Events

* **`Database — Table Events`** : database table create / drop / truncate
* **`Database — Record Events`** : database table insert / update / delete / upsert
* **`Job Management`** : job started / job ended
* **`File Arrival`** : schedule modified, schedule job triggered, file dropped, email received

### Recap

Without defining or raising anything, you subscribed to the built-in `DatabaseTableCreated` event and logged every table creation — optionally filtered to a single table with a match value. Subscribing to any other system event follows the same two steps; only the event you select and the payload fields you map differ.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://documentation.astera.com/project-management-and-scheduling/events/system-events.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.