Short Term Limitations

Private preview: The Marketplace app is available to select accounts. Reach out to your Immuta representative for details.

Marketplace is a private preview feature and has several known limitations that will be addressed by end of Q1 2025.

Known short term limitations

No API support

Everything will be backed by APIs, and APIs will be a first class citizen of Marketplace. However, we are still working through API authentication, and due to this, they are not available for use, yet, but will soon.

No notifications

Users must visit the Marketplace to see pending requests or request status. Soon notifications will be supported for email, webhooks, Teams, Slack.

Searching within the Marketplace

You are able to search by data product name and description. In the future, we intend to add rich search and discovery capabilities using LLMs that leverage details about the data, the users, the request question answers, and audit history to make recommendations based on described use case by the consumer (this will be an ongoing effort that will not be completed in Q1 2025).

Data stewards cannot be assigned

Data stewards cannot be assigned to manage approvals. Only users with GOVERNANCE permission or Manage Data Product in the domain where the data product was created can make determinations on requests. Soon assignment of data stewards will be supported.

Questions asked as part of an access request cannot be changed

All data products will have the same hard coded question asked of every user that requests access to it: What about your responsibilities, your use case, and this data requires you to have access to this data product? Soon, managing the questions asked will be fully configurable and reusable, similar to data use agreements.

Policy, tag, and user attribute administration in Immuta is unprotected

Marketplace provisions access through a single policy that reacts to tags Marketplace places on data sources and attributes marketplace places on users. That policy, those tags, and those attributes are currently unprotected, meaning, you can delete them, alter them, and or use them in policies in the Governance app. Soon they will be protected, and this will not be possible.

Do not edit, alter, or use the policy, tags, or attributes that the Marketplace app creates. It can break your integration and access.

Domains do not support dynamically adding data sources

Currently, the only way to add data sources to a domain is by manual selection by a user with GOVERNANCE permission. This can be problematic for ensuring new data created for data products appears in a domain so it can be published in a data product. Soon Immuta will support adding data sources to a domain by the schema or database that contains them or tags placed on them.

Always required subscription policies will revoke access

The default setting for Immuta Allow users with specific groups/attributes subscription policies is Always Required which is how subscription policy merging behavior is defined. When the Always Required option is selected (the default) and merged with other subscription policies, they are ANDed together. If Share Responsibility is selected, they are ORed together.

This is problematic for Marketplace because the policy that does the provisioning via Marketplace upon approval is merged with any existing subscription policies on the data sources in the data product. That means if your subscription policy is Always Required it will merge with the Marketplace policy using an AND and revoke all existing users access until they are approved through the Marketplace.

To avoid this, if you are not leveraging subscription policy merging today, convert your Allow users with specific groups/attributes subscription policies that touch data sources in your data products from Always Required to Share Responsibility.

Soon Immuta will alter this behavior in a way that allows you to keep using Always Required as normal, but not result in existing users losing access.

Some obsolete subscription policies and their settings still exist

• Subscription policy type Allow anyone who asks (and is approved) is still available, but is obsolete, because you should be doing this in Marketplace instead. If you have some of these policies, we recommend the following:

  • Convert the data sources the policy targets to a data product.

  • Publish the new data products in Marketplace to allow users to ask for access.

  • Delete the previous subscription policy.

• Subscription policy type Allow users with specific groups/attributes can still be used, but some of the settings are unnecessary with Marketplace:

  • Require Manual Subscription: If you are using this setting, instead use the following workaround:

    • Create a separate subscription policy that targets the same data sources:

      • The Allow users with specific groups/attributes requires you are in a group that contains no users (meaning it subscribes no one)

      • It is set to Share Responsibility

    • Uncheck the Require Manual Subscription option in the existing policy

    • Ensure all data sources this policy targets are published in the Marketplace in data products

    Once you complete those steps, the shorthand version of your merged policy per data source will look like this, achieving the same goal: allow users to subscribe who are members of group [your original requirement] AND (are members of group [nobody] OR approved in Marketplace). Soon Immuta will make it easier to set a "required" subscription policy that does not auto-subscribe until access is requested (and potentially auto-approved) in Marketplace.

  • Allow Data Source Discovery: Instead of this setting, simply publish the data source to the Marketplace in a data product.

  • Request Approval to Access: Instead of this setting, consider converting the data sources these policies target to data products in the Marketplace, and allow the approvals to happen there.

Soon these obsolete subscription types will be altered and/or deprecated.

Limited audit

Marketplace actions are not audited yet; that is coming soon.

Approvals cannot be time bound

Currently an access request can be approved or denied. Soon approvals will support being time bound. For example, you are temporarily approved for 30 days, or you are temporarily approved until December 25th 2024.