Users can now set up a Snowflake integration using a Snowflake Native App (SNA).

This deployment offers an alternative to the connection process outlined here, with the following benefits:

1. No Snowflake credentials are stored in the Monte Carlo Cloud.
2. Connectivity is initiated from your Snowflake account to Monte Carlo.
3. No cloud deployments (e.g., in AWS or Azure) are needed, as the agent is hosted in Snowflake as a Native App.
4. You may be able to use Snowflake credits for Monte Carlo. Contact your Monte Carlo and Snowflake representatives for more information.

Learn more about the SNA agent (public preview) at this link: https://mc-d.io/sna

Users can now segment by up to 5 fields by creating a Metric Monitor. The previous limit was 2 fields. As we've increased other limits on scale in metric monitors, it made sense to increase this one as well to support more heavily segmented use cases.

Users could previously accommodate this need by concatenating those fields in the "By SQL Expression" option, but that was clunky.

Read more about segmentation in Metric monitors.

A frustrating limitation has been removed from Metric monitors.

Previously, when using segmentation, users were limited to monitoring only a single metric. That limitation is now removed, and instead users are limited to tracking 10,000 combinations of metrics/fields/segments within a single monitor. This gives users more flexibility to meet their metric monitoring needs with less configuration.

See this doc to learn more.

Setting variable values for Custom SQL monitors is more flexible now. While it has been possible to define static values for a while, it is now possible to set variable values at runtime via both the UI and API.

Excluded tables are now called out separately in the upstream coverage charts across the UI. This helps users distinguish between upstream tables that are excluded from being monitored through an explicit rule in the Usage UI, from those that do not have any matching rules to include or exclude them in monitoring. These new details will impact upstream coverage charts in several places across our UI:

• Data Product list page
• Data Product Coverage tab
• Asset Search page
• Asset details page

Volume monitors are now available for Oracle DB. Users will get automated volume metrics and anomaly detections; they can also set explicit thresholds for volume monitors. Updated docs here.

The ServiceNow integration now supports authenticating via OAuth.

Three key improvements were just shipped for the Monte Carlo <> Jira integration:

• Support for required fields. Previously, the integration did not natively support required fields, so if your Jira environment required more than the minimum to create an Issue, you could not proceed. Now, any required fields are surfaced directly in Monte Carlo so the user can fill them out.
• “Owner” of the Jira issue can now be assigned from within Monte Carlo. Previously, owner was defaulted to the user that had set up the API key used for the integration.
• More alert information is included in the description. The information we pass into the description is now at parity with what Monte Carlo would send in a notification, making is easier to understand what has happened.

We've made it easier to select what Audiences a Data Product's out-of-the-box detectors should route to, right from the creation and edit flow.

Now, when you create a Data Product, you will be able to select an existing Audience (or create a new one) to automatically route alerts to from the Data Product. This is essentially handling the creation of a Notification Rule under "Other notifications" to route "Affected data" by that Asset tag for the Data Product to that Audience.

Additionally, on the Data Product Coverage Tab you can see which Audiences are associated with this Data Product.
Note: We only show the Audiences where there is a Notification rule that specifies only that Data Product Asset tag and no other conditions. i.e. if the Notification Rule said "Include Data Product tag but exclude this other tag" it would not show up in this section.

Custom monitor failure notifications due to misconfigurations used to be limited to a frequency of 1 notification per week. We've changed the frequency to up to 1 notification per day in order to reduce the risk of monitor failing silently while still being mindful of alert fatigue.