登録して招待リンクを共有すると、動画再生報酬と紹介報酬を獲得できます。

cv usk
@cv_usk
AI / Software Research Notes AI Agent, LLMOps, MLOps, Software Architecture 投稿は個人の意見です。
参加 May 2026
258 フォロー中    228 ファン
# Learning Palantir Foundry 🚀 "Sales reps see only the rows for their assigned customers" — achieved on a single dataset, without spawning a copy per department. That is what Restricted Views (row-level security) deliver. 📌 Title and Feature URL Title: 制限付きビュー(行レベルセキュリティ) URL: 📝 Overview Restricted Views implement granular row-level access control. A restricted view is built on top of a backing dataset and lets different users see different subsets of the same underlying data based on defined permissions. This removes the need to copy datasets per team: you keep one dataset as the source of truth shared across the company while splitting visibility at the row level. 🔧 How It Works Restricted views operate through policies containing rules that determine row visibility. - Policies evaluate the viewing user's attributes, column names from the backing dataset, and specific values (strings, Booleans, numbers, arrays) to decide which rows are shown. - When referencing users, groups, or organizations, you must use the unique identifier (UUID) in both the policy column and the policy definition — names alone will not work. - In marking-backed views, the upstream dataset holds a STRING ARRAY column of Marking IDs, and each row is visible only to users with the required markings. - A restricted view is built on top of a backing dataset and cannot be used as an input for transforms. - Experimental branching support allows adding and merging restricted view policy changes. 🛠 Practical Usage - Add a column to the backing dataset that drives row access (for example, assigned branch or organization ID). - Define a policy that matches that column against user attributes to build the row-level filter. - Save restricted views in a separate Project from the source datasets to keep access management clean. - For markings, attach an array of required Marking IDs per row to control visibility. 🎯 Use Cases - Limit sales representatives to viewing customers at their assigned branch. - Separate records on a shared table by department or organization. - Disclose differently classified records only to users holding the required markings. ⚠️ Caveats - Restricted views cannot serve as transform inputs, so they cannot be plugged directly into downstream pipeline processing. - Users, groups, and organizations must be referenced by UUID; name-based references do not work. - Merging policy changes via branching is experimental and may not be universally available. #PalantirFoundry# #DataGovernance#
もっと見る