# Palantir Foundryを学ぶ 🚀 「このダッシュボードの数字、どこから来たの?」に即答できる。Data Lineageは、データの流れをまるごと可視化する探索ツールです。 📌 タイトルと機能のURL タイトル: データリネージ URL: 📝 概要 Data Lineageは、Foundryプラットフォーム上をデータがどう流れるかを包括的に示すインタラクティブな可視化ツールです。データの移動・依存関係・変換を、データエコシステム全体にわたって理解できます。ソースからパイプライン、オントロジー、アプリへと続く系譜をグラフとして辿れるため、障害対応や監査説明のコストを大きく下げられます。 🔧 機能の説明 グラフベースのビジュアライゼーションでデータの依存関係を表現します。 ・プロジェクト名・テーブル識別子・行ラベルを使ってデータセットを検索でき、Foundry Projects上から直接データを閲覧できます ・任意のデータセットについて、上流(祖先)と下流(子孫)の関係を展開・折りたたみできます ・複数のテーブル属性を同時に表示し、スキーマ詳細・ビルドのタイムスタンプ・ソースコードまで確認できます ・カスタムのカラースキームを適用して、古くなった(stale)データセットなどパイプラインの特性を強調できます ・共有可能なパイプラインのスナップショットを作成し、チーム内で共有できます 🛠 実践的な使い方 ・ダッシュボードや出力データセットから上流をたどり、数字の出所(ソース)を特定します ・上流のスキーマ変更があった際に、下流をたどって影響範囲を洗い出します ・カラースキームで古いデータセットを色分けし、放置されたパイプラインを発見します ・高レベルの全体像から、変換コードや実行履歴といった粒度の細かい技術詳細へドリルダウンします ・パイプラインのスナップショットを共有してデータワークフローを部門横断で文書化します 🎯 ユースケース ・「このダッシュボードの数字の出所」を即座に回答 ・上流スキーマ変更の影響範囲を事前に特定し、障害を未然に防止 ・監査時にデータの系譜を提示して説明コストを削減 ・古い・未使用のデータセットを発見してパイプラインを整理 ⚠️ 注意点 ・本概要ページでは、極端に大規模なパイプラインでのパフォーマンスやグラフの複雑さに関する制約は明示されていません ・リネージはFoundryプラットフォーム内のデータフローを対象とし、プラットフォーム外の処理は可視化の範囲外となります ・系譜の正確さは、変換やパイプラインがFoundry上で適切に構成されていることに依存します #PalantirFoundry# #DataLineage#

# Palantir Foundryを学ぶ 🚀 数十億行のテーブルを毎日まるごと再計算していませんか。差分だけを処理すれば、コンピュート費は劇的に下がります。 📌 タイトルと機能のURL タイトル: インクリメンタル変換 URL: 📝 概要 インクリメンタル変換は、前回の実行以降に追加・変更されたデータだけを処理することで、効率的なデータ処理を実現する仕組みです。データセット全体を再処理する代わりに、差分のみを扱います。`@incremental()`デコレータを付けることで有効になり、入力の変化パターンに応じてインクリメンタル実行とスナップショット実行を自動的に切り替えます。 🔧 機能の説明 `@incremental()`デコレータは、トランスフォーム関数をラップして差分処理の能力を付与します。 ・標準の入出力オブジェクトを、`IncrementalTransformInput` / `IncrementalTransformOutput` / `IncrementalTransformContext` といったインクリメンタル版に変換します ・入力の読み取りモードは、`added`(前回以降の新規行・既定)/ `previous`(前回実行時の状態)/ `current`(現在のデータセット全体)を選べます ・出力の書き込みモードは、`modify`(既存出力に追記)/ `replace`(出力全体を上書き)があり、インクリメンタル時の既定は`modify`、スナップショット時は`replace`です ・主なパラメータには、`require_incremental`(差分実行不能なら失敗させる)、`semantic_version`(値を上げるとスナップショット再構築を誘発)、`snapshot_inputs`(特定入力を差分制約から除外)、`strict_append`(追記専用の安全性を強制)などがあります 🛠 実践的な使い方 ・追記中心の大規模ログ・トランザクションテーブルに`@incremental()`を付け、毎日のフル再計算を差分処理に置き換えます ・ロジックを変更したら`semantic_version`を上げ、安全にスナップショット再構築を走らせます ・全件再処理を許したくない場合は`require_incremental`で差分実行を強制します ・厳密な追記保証が必要な場面では`strict_append`を使います 🎯 ユースケース ・数十億行テーブルの毎日フル再計算によるコンピュート費高騰を、差分処理で大幅削減 ・大規模案件の採算性を左右するコスト最適化の中核技術として活用 ・追記専用の取引履歴・イベントログの日次取り込み ・上流が追加のみ(APPEND/UPDATE)で増えるパイプラインの効率化 ⚠️ 注意点 ・プレビュー機能は常に非インクリメンタルで実行されます ・すべての非スナップショット入力が「追加のみ(APPEND/UPDATEトランザクション)」である、入力リストが安定している、`semantic_version`が変わっていない、などの要件を満たさない限り、自動的にスナップショットモードで実行され出力が全置換されます ・更新・削除された入力ファイルはスナップショット入力としてマークする必要があります ・`previous`モードは前回出力の構造に一致するスキーマ検証を要します ・トランスフォームのロジックはインクリメンタルとスナップショットの両方の実行経路に対応している必要があります #PalantirFoundry# #DataEngineering#

# Palantir Foundryを学ぶ 🚀 ノーコードでは届かない複雑なロジックを、ソフトウェア工学の品質管理ごとデータ基盤に持ち込む。それがCode Repositoriesです。 📌 タイトルと機能のURL タイトル: Code Repositories(Pythonトランスフォーム) URL: 📝 概要 Code Repositoriesは、Foundry内で本番品質のコードを作成・協働するためのWebベースの統合開発環境(IDE)です。基盤にあるGitリポジトリをブラウザのUIから操作でき、コマンドライン無しでチーム開発を進められます。プラットフォーム固有の機能を備え、データエンジニアリングにソフトウェア開発の作法をそのまま適用できます。 🔧 機能の説明 バージョン管理とコラボレーションが中核です。 ・ブランチ作成・コミット・リリースタグ付けといったGit操作をWeb UIから実行できます ・プルリクエスト(PR)でコードレビューを行い、権限は「高度に設定可能」でレビュー必須化などの品質保証を支えます ・IntelliSense、リンティング、エラーチェック、文脈に応じたヘルプダイアログがすべてのリポジトリ種別で利用できます ・Transformsリポジトリでは、Python・Java・SQLでのデータ変換ロジックを記述し、プレビューとデバッグが可能です ・FunctionsリポジトリはオントロジーをネイティブにサポートしTypeScript/Pythonで低レイテンシのビジネスロジックを実装できます 🛠 実践的な使い方 ・PySparkを用いて、数十億行規模の名寄せや複雑な業務ルールをコードで実装します ・PRレビューを必須に設定し、マージ前に第三者の確認とCIチェックを通すことを強制します ・ユニットテストを組み込み、変換ロジックの回帰を防ぎます ・Functionsリポジトリでは、オントロジーのデータ型に基づくオートコンプリートを活かして安全にロジックを記述します ・モデル開発リポジトリで機械学習ワークフローもプラットフォーム内に取り込みます 🎯 ユースケース ・Pipeline Builderでは表現しきれない複雑な名寄せ・業務ルールをPySparkで実装 ・「本番直編集によるデグレ」を、レビュー必須化とブランチ運用で構造的に排除 ・派生KPIや検証ロジックをFunctionsとして実装し、各アプリから再利用 ・MLモデルの学習・推論コードをガバナンス下で管理 ⚠️ 注意点 ・ドキュメントの日本語訳は機械生成で未検証である旨が記載されており、ローカライズ内容には精度上の限界がある可能性があります ・リポジトリ種別(Transforms/Functions/Model)ごとに対応言語や用途が異なるため、目的に合った種別を選ぶ必要があります ・プロコード環境ゆえ、レビュー・CI・テストの運用ルールを組織として整備しないと品質管理の効果が出ません #PalantirFoundry# #DataEngineering#

# Palantir Foundryを学ぶ 🚀 「閉域網のオンプレOracleやSAPに、ファイアウォールに穴を開けずどう繋ぐ？」エンタープライズ導入の最初の関門を突破するのがData Connectionです。 📌 タイトルと機能のURL タイトル: Data Connection URL: 📝 概要 Data Connectionは、外部システムのデータをFoundryに同期し、データ統合・モデリング・オントロジーの各レイヤーで利用できるようにするアプリケーションです。Webhookやデータエクスポートによる外部システムへの書き戻し（アウトバウンド）にも対応します。多数のソースタイプに対応し、認証・スケジュール・監視といった煩雑な部分を抽象化して、シンプルな画面からパイプラインを構成できます。 🔧 機能の説明 Foundryのデータ接続は、3つの原則に沿って標準化されています。 ・堅牢性: 自動リトライ、小さなバッチ単位での処理、ヘルス監視による障害警告を備えます。データは「最も原始的なソースからそのまま（as-is）」取り込み、Foundryのバージョン管理されたパイプラインを唯一の正（single source of truth）とすることで、外部前処理に依存しません ・拡張性: データベース、FTPS、HDFS、S3、SFTPなどの標準連携に加え、新しいソースタイプにも対応できます。スケジューリングやオーケストレーションといった中核機能は標準化されているため、接続固有の調整だけで済みます ・使いやすさ: 複雑さを抽象化し、認証・スケジュール・監視を手作業で管理する代わりに、シンプルなインターフェースで構成できます ・主要な構成要素として、エージェントのセットアップ、ソース構成、バッチ／ストリーミングの同期、Webhook、エクスポートを備えます 🛠 実践的な使い方 ・ワークスペースのナビゲーションまたはアプリケーションポータルからData Connectionにアクセスします ・接続先（ソース）を構成し、バッチまたはストリーミングの同期（sync）を設定して、データを「そのまま」取り込みます ・取り込み後の変換はFoundry側のパイプラインに集約し、ソース側では前処理を行わないようにします ・書き戻しが必要な場合は、Webhookやエクスポートでアウトバウンド連携を構成します 🎯 ユースケース ・閉域網のオンプレOracle/SAPを、エージェント方式（アウトバウンドのみで成立）でFW穴あけなしに接続 ・データベース・SFTP・S3など多様なソースからの定期バッチ取り込み ・処理結果を外部システムへ書き戻すアウトバウンド連携 ⚠️ 注意点 ・データはソースから「as-is」で取り込み、変換はFoundryのパイプラインに寄せる設計が前提です。ソース側で加工すると追跡性が損なわれます ・エージェントやソースの構成には、ネットワーク・認証の適切な準備が必要です ・X APIなど外部サービスの上限や規約は仮定せず、接続先ごとの制約を事前に確認してください #PalantirFoundry# #DataIntegration#

# Palantir Foundryを学ぶ 🚀 「営業は自分の担当顧客の行だけ見える」を、データセットを部門ごとにコピーすることなく実現する仕組み。それが制限付きビュー（行レベルセキュリティ）です。 📌 タイトルと機能のURL タイトル: 制限付きビュー(行レベルセキュリティ) URL: 📝 概要 制限付きビュー（Restricted Views）は、1つの基盤データセットの上に構築される、行レベルのアクセス制御の仕組みです。同じ元データに対して、閲覧するユーザーごとに見える行のサブセットを変えられます。これにより「部門別にデータをコピーして配る」運用をやめ、単一データセットを正として全社で共有しながら、権限だけを行単位で分けられます。 🔧 機能の説明 制限付きビューは、行の可視性を決めるルールを持つ「ポリシー」によって動作します。 ・ポリシーは、閲覧ユーザーの属性、基盤データセットの列名、特定の値（文字列・真偽値・数値・配列）を評価して、どの行を見せるかを判定します ・ユーザー・グループ・組織を参照する場合は、名前ではなく一意の識別子（UUID）をポリシー列とポリシー定義の両方で指定する必要があります ・マーキング連携型では、上流データセットにマーキングIDの文字列配列の列を持たせ、各行は必要なマーキングを持つユーザーにのみ表示されます ・制限付きビューは基盤データセットの上に構築され、トランスフォーム（変換）の入力としては使用できません ・ポリシー変更の追加・マージを扱う実験的なブランチ対応も提供されています 🛠 実践的な使い方 ・基盤データセットに、各行のアクセス可否を判定するための列（担当拠点、組織IDなど）を用意します ・その列とユーザー属性を突き合わせるポリシーを定義し、行レベルのフィルタを構成します ・権限管理を明確にするため、制限付きビューは元データセットとは別のプロジェクトに保存するのが一般的です ・マーキングを使う場合は、行ごとに必要なマーキングIDの配列を持たせて可視性を制御します 🎯 ユースケース ・営業担当が、自分の担当拠点の顧客行のみを閲覧できるようにする ・部門・組織単位で、同一テーブル上のレコードを分離して見せる ・機密度の異なるレコードを、マーキング保有者だけに開示する ⚠️ 注意点 ・制限付きビューはトランスフォームの入力に使えないため、下流のパイプライン処理に直接組み込めません ・ユーザー・グループ・組織はUUIDで指定する必要があり、名前指定では機能しません ・ブランチによるポリシー変更のマージは実験的機能であり、環境によっては利用できない場合があります #PalantirFoundry# #DataGovernance#

# Palantir Foundryを学ぶ 🚀 「この顧客の情報、結局どの画面を何枚開けば全部わかるの？」という現場の悩みを一発で解消するのがオブジェクトビューです。1つのオブジェクトに関わる情報と操作を、1画面に束ねます。 📌 タイトルと機能のURL タイトル: オブジェクトビュー URL: 📝 概要 オブジェクトビューは、特定のオブジェクトに関するあらゆる情報とワークフローを集約する中心的なハブです。プロパティ、関連リンク先のオブジェクト、メトリクスや分析、ダッシュボード、そして業務アプリケーションを1つの統合インターフェースにまとめます。たとえば「空港」オブジェクトのビューであれば、フライトのタイムライン、遅延対応のワークフロー、位置情報を1画面で扱えるようになります。現場ユーザーが日々最初に開く「業務のホーム画面」として機能します。 🔧 機能の説明 オブジェクトビューは、ビルダーが柔軟に設計・カスタマイズできる構成になっています。 ・複数のフォーマットやサイズに対応し、用途に応じて見た目や操作パターンを設計できます ・プロパティ（属性）、関連リンク先のオブジェクト、メトリクス、分析、ダッシュボードを統合して表示できます ・プラットフォーム全体の各所に埋め込んで配置できます ・設定はOntology Managerの「オブジェクトビュー」タブから行い、ビュー上部のタブでフォーマットのバージョンを切り替えられます ・「ビューを編集」を選ぶと、構成エディタや背後のWorkshopモジュールにアクセスできます ・バージョン管理、パネルのバリエーション、コメント機能、Marketplace製品との連携にも対応しています 🛠 実践的な使い方 ・Ontology Managerで対象のオブジェクトタイプを選び、「オブジェクトビュー」タブからプレビューと設定を行います ・基本情報、関連オブジェクト、操作履歴、埋め込みダッシュボードをレイアウトして、現場が必要とする情報を1画面にまとめます ・閲覧だけでなく、アクションタイプを組み込むことで、ビューから直接ステータス変更や割当などの操作を実行できる導線を作れます ・複数フォーマットを用意し、役割（例: 営業向け／保全担当向け）に応じた見せ方を切り替えます 🎯 ユースケース ・顧客360: 取引履歴・問い合わせ・関連注文・担当者を1画面に集約した営業の起点画面 ・設備カルテ: センサー値・保全履歴・関連部品・対応中チケットをまとめた保全担当のホーム画面 ・案件管理: 案件オブジェクトに対し、関係者・期日・承認状況・次アクションを一望 ⚠️ 注意点 ・ビューはオントロジーのモデリング（オブジェクトタイプ・リンクタイプ）の品質に依存します。土台が弱いと良いビューは作れません ・情報を詰め込みすぎると現場が迷うため、役割ごとに見せる項目を絞る設計が重要です ・編集にはOntology Managerおよび背後のWorkshopモジュールへの適切な権限が必要です #PalantirFoundry# #DataPlatform#

# Palantir Foundryを学ぶ 🚀 ビジネスロジックをオントロジーに常駐させる。ファンクションは「部門間で数字が合わない」問題を、ロジックの一元化で根治します。 📌 タイトルと機能のURL タイトル: ファンクション URL: 📝 概要 ファンクションは、隔離された環境でサーバーサイドのロジックを実行する仕組みです。ダッシュボードや意思決定支援といったオペレーショナルアプリを支えます。Foundryのオントロジーと連携して動くよう設計されており、オブジェクトのプロパティ読み取り、リンクの走査、柔軟なオントロジー編集が行えます。 🔧 機能の説明 ・対応言語: TypeScript(フル機能対応)と Python(ベータ、特にサーバーレス/デプロイ実行で対応が拡大中)をサポートします。 ・サーバーレス実行: 呼び出し時にオンデマンドで起動し、実行時のみ課金されます。合計60秒のウォールクロックタイムアウト(CPU30秒+ネットワーク30秒)があります。複数バージョンを同時稼働でき、アップグレードを安全にします。 ・デプロイ実行: 専有リソースを確保する方式で、サーバーレスで要件を満たせない場合に有効です。単一バージョンを稼働させ、デプロイ中は継続課金されます。 ・機能差: オントロジーの読み書きやWorkshop連携・外部API呼び出しは両言語で可能。Pipeline BuilderはPython、モデル埋め込みやセマンティック検索はTypeScriptが対応します。 🛠 実践的な使い方 ・派生プロパティ: 計算列としてファンクションで算出した値を表示します。 ・ファンクション付きアクション: 複数オブジェクトにまたがる複雑な編集を実装します。 ・Workshop連携: 変数の計算や表示のためにファンクションを実行します。 ・APIゲートウェイ: クエリ系ファンクションをプログラムから呼び出し、同一ロジックを再利用します。 🎯 ユースケース ・派生KPIの算出ロジックを一元実装し、Workshop/OSDK/APIから同じ結果を返す。 ・外部システムを照会してオントロジーのオブジェクトをエンリッチする。 ・複雑な検証や一括更新を、ファンクション付きアクションとして実装する。 ⚠️ 注意点 ・60秒のタイムアウトが全実行モードに一律適用されるため、効率的な実装が求められます。 ・呼び出しコンテキストにより利用可能な機能が変わります(例: モデル埋め込みやセマンティック検索はTypeScriptのみ)。言語選定は早めに見極めてください。 #PalantirFoundry# #DataEngineering#

# Palantir Foundryを学ぶ 🚀 Foundryを「読み取り専用BI」と決定的に分かつのがアクションタイプ。承認も割当も、検証付きの構造化操作として安全に書き込みます。 📌 タイトルと機能のURL タイトル: アクションタイプ URL: 📝 概要 アクションタイプは、利用者がオントロジーのオブジェクト・プロパティ・リンクに対して、1つのトランザクションで適用できる変更のまとまりを定義します。データの変更と、提出時に発生する副作用の両方をカプセル化します。これにより、個別のプロパティ編集ではなく「達成したいゴール」の単位で操作を考えられます。 🔧 機能の説明 ・オントロジーへの書き込み: アクション実行時、すべての変更がオントロジーにコミットされ、すべてのアプリに反映されます。利用者の編集を含む最新のオブジェクトデータは、オブジェクトタイプの書き戻し(write-back)データセットに記録されます。 ・パラメータと既定値: 入力を標準化するためのパラメータを使い、既定値の設定、ドロップダウン結果のフィルタ、上書きなどを行えます。 ・ルール: アクションがいつどう実行されるかを規定し、オブジェクトの関係やプロパティ制約を含む条件・ロジックを定義します。 ・提出基準と検証: 変更が永続化される前に、実行可否やエラー処理を制御する検証ルールを設定できます。 ・アクションログ: 実行されたすべてのアクションの監査証跡を保持し、説明責任とコンプライアンスを支えます。 🛠 実践的な使い方 ・「従業員の割当」アクションのように、ロールプロパティの変更・マネージャー従業員リンクの自動生成・関係者への通知を1トランザクションで実行します。 ・「100万円超は部長のみ提出可」のような提出基準を検証として組み込み、Excel+メールの承認フローを構造化操作へ置換します。 ・同じ検証ロジックとワークフローを、すべてのユーザー向けアプリで共通利用します。 🎯 ユースケース ・ステータス変更・承認・割当を、権限と基準付きの操作として標準化する。 ・複数オブジェクトにまたがる多段の変更を、非技術者でも安全に実行する。 ・全操作のアクションログを内部統制・監査の証跡として活用する。 ⚠️ 注意点 ・アクションは検証ルールを通過しなければ実行されません。提出基準の設計が業務統制の質を左右します。 ・変更はオントロジー全体・全アプリに即時反映されるため、ルールとパラメータの設計を曖昧にしないことが重要です。 #PalantirFoundry# #Ontology#

# Palantir Foundryを学ぶ 🚀 データセットを「業務オブジェクト」に変える最初の一手。オブジェクトタイプの設計が、後段アプリの性能とUXをほぼ決めます。 📌 タイトルと機能のURL タイトル: オブジェクトタイプ URL: 📝 概要 オブジェクトタイプは、現実世界のエンティティやイベントのスキーマを定義するものです。1件の実体は「オブジェクトインスタンス」(例: 従業員「Melissa Chang」)、複数のまとまりは「オブジェクトセット」(例: すべての在籍従業員)として扱います。これはデータセットが行と絞り込み行集合を扱う構造に対応します。 🔧 機能の説明 ・主キーと同一性: オブジェクトはインスタンスを一意に識別する主キーを必要とします。データソースをオブジェクトタイプにマッピングすることで、アプリ上でオブジェクトを生成・表示できます。 ・プロパティ: オブジェクトの特性を定義します。編集専用プロパティ、必須プロパティ、複数タイプで再利用する共有プロパティなどの構成が可能です。 ・プロパティ型: 時系列データ、地理空間情報、構造体(struct、入れ子の複合プロパティ)など多様な型をサポートします。 ・表示と検索: タイトル/表示の設定や検索インデックスにより、アプリ内での発見性を高めます。 ・値型(Value Types): バージョン・権限・制約を備えたカスタム値型で、オントロジー全体に標準化された表現を与えられます。 🛠 実践的な使い方 ・従業員ディレクトリや基幹データを「従業員」オブジェクトタイプに接続し、生のデータセットを操作可能なオントロジーのインスタンスへ変換します。 ・主キー設計を最初に固め、検索インデックスを適切に張ることで、後段アプリの検索性能とUXを担保します。 ・構造体プロパティで階層データを自動マッピングし、共有プロパティと組み合わせて再利用性を高めます。 🎯 ユースケース ・顧客マスタを「顧客」オブジェクト化し、全社で一意の顧客像を扱う。 ・センサーを持つ設備を時系列プロパティ付きでモデリングし、稼働履歴を保持する。 ・拠点・店舗を地理空間プロパティでモデリングし、地図上での集計・検索を可能にする。 ⚠️ 注意点 ・主キー設計・プロパティ型・検索インデックスの選択が、後段のアプリ性能とUXをほぼ決定します。最重要のモデリング判断として慎重に設計してください。 ・オブジェクトを生成・表示するには、データソースをオブジェクトタイプへ正しくマッピングすることが前提になります。 #PalantirFoundry# #Ontology#

# Learning Palantir Foundry 🚀 "How many screens do I need to open just to understand one customer?" Object Views answer that pain by bundling everything about a single object into one screen. 📌 Title and Feature URL Title: オブジェクトビュー URL: 📝 Overview Object Views act as the central hub for everything related to a specific object. They consolidate properties, linked objects, metrics and analytics, dashboards, and operational applications into a single unified interface. For example, an Airport object view can integrate flight timelines, delay-handling workflows, and location data in one place. In practice, an Object View becomes the daily "home screen" that frontline users open to start their work. 🔧 How It Works Object Views are highly configurable by builders: - They support multiple formats and sizes, so appearance and interaction patterns can be tailored to the task. - They combine properties (attributes), linked objects, metrics, analytics, and dashboards into one display. - They can be embedded throughout the platform wherever the object appears. - Configuration happens in the Ontology Manager under the "Object views" tab, and version tabs at the top let you switch between format variations. - Selecting "Edit views" opens the configuration editor or the underlying Workshop module. - The system also supports version management, panel variations, commenting, and Marketplace product integration. 🛠 Practical Usage - In Ontology Manager, select the target object type and use the "Object views" tab to preview and configure. - Lay out core information, related objects, operation history, and embedded dashboards so everything the team needs is on one screen. - Beyond viewing, embed action types so users can trigger status changes or assignments directly from the view. - Create multiple formats to show different layouts per role (for example, sales view vs. maintenance view). 🎯 Use Cases - Customer 360: one launchpad combining transaction history, inquiries, related orders, and account owners for sales. - Equipment record: a maintenance home screen with sensor values, service history, related parts, and open tickets. - Case management: a single view of stakeholders, due dates, approval status, and next actions on a case object. ⚠️ Caveats - Views depend on the quality of the underlying ontology modeling (object types and link types); a weak foundation limits view quality. - Overloading a view confuses users, so design role-specific layouts that show only what each role needs. - Editing requires appropriate permissions to the Ontology Manager and the underlying Workshop module. #PalantirFoundry# #DataPlatform#