Context:
This improvement proposal is relevant in the context of enrollments with multiple organizations.
There’s an Organization primitive available in the Access Graph. However, it is not possible to expand nor it provides any capabilities covering data inflows/outflows for a single organization:
When multiple organizations operate in the same enrollment, it would be great with one click to have an eagle-eye view of the 1) data exchanges, and 2) visibility. An example/idea, is presented below:
Why we cannot do it today:
There’s no native capability to monitor where OrgMarkings are being expanded. The data lineage capabilities greatly fulfill requirements that are relevant for engineers or within a single project context. However, it is not the right abstraction for a platform-wide overview.
Workarounds:
One could attempt scraping all code repositories and apply a regex to find “stop_propagating”. However, requires scanning over the whole platform and the ability to establish the right data model and links.
Benefits::
Clear auditability and a tool to govern and control data flows across multiple organizations in an enrollment at scale.
Summarize all the data outflows from an Organization, and address key questions and strategic priorities relevant to those in high level executive roles - CDO, enterprise architects, and auditors.
PS: Inflows of data are in the data connection app. Representing this data exchange flows in the Access Graph is just an idea but not necessarily the best (disclaimer: I am not a product designer). It can be argued that a separate application is required to fulfill all these requirements. I hope this provides a good inspiration and I leave to the product team to design and understand what’s the most appropriate path forward.
Thank you for the thoughtful message. I apologize you posted it so long ago and nobody has responded.
You have accurately identified that today access graph has limited functionality. I agree with you that seeing this sort of information on a graph would be useful.
What is all the information you wish access graph had?
Do you think access graph is the right place or do you think it should be merged with monocle or workflow builder so you are able to see other types of connections as well?
Do you think only providing this information in graph form is sufficient or would it be more helpful to give this information in dataset or object form and let you run explorations with object explorer / vertex / etc.
Let me take a step back and provide some context to highlight why this feature request carries broader significance—it’s not just for adhoc analysis and developers.
Context:
Foundry has the potential to be much more than an internal tool for analytics or application development. With foundational security capabilities like Organization Markings, private spaces, and ontologies, it empowers organizations to extend beyond internal use cases and support business-to-client (B2C) initiatives. To the best of my knowledge, no platform in the market offers such primitives in an intuitive, and enterprise-ready way.
B2C engagements, especially those involving licensed data, come with a host of legal and governance requirements. These often include controlling and limiting user access, tracking data usage, and preserving records of what was shared—even after an engagement ends. Since expanding OrgMarkings are implemented by engineers through PRs, there’s always a margin for error and growing organically. This reality makes it critical for enterprise architects to monitor and have clear visibility into the data being shared and managed across the organization, and to have tools that support this oversight.
While Collibra offers support in this area, it often relies heavily on manual intervention. Foundry, on the other hand, has the potential to be a more effective auditing tool since it already hosts the security primitives. The only missing piece is surfacing this information in the right format.
Coming back to your points:
From my perspective, the removal of Organization Markings sits closer to the south of ontology and data engineering layer. As such, I believe the best way to surface or represent this information would be:
As a dataset—or alternatively, through an API endpoint exposed in the Platform SDK to enable programmatic access. This approach would offer maximum flexibility, allowing seamless integration with external tools when required by auditors.
