Video summary

Developer Deskside | Building a Ticket Framework in Foundry

Main summary

Key takeaways

Technology

Technological summary (Foundry “ticket framework” build)

  • Video purpose / series format

    • Starts a long-form “developer desk sides” series where a Palantir engineer builds an operational app end-to-end in Foundry.
    • Focus: a ticket management system implemented with Foundry’s Object Layer concepts—object types, link types, actions, and then Workshop UI modules.

  • Product concept / workflow modeled

    • Real-world operational workflows are reduced to tickets that have:
      • assignment (assignee)
      • a status lifecycle (e.g., backlog → active → complete, plus dscoped)
      • context through comments
      • optional file attachments
      • a need for history/logging (status transition timeline + audit-like records)

  • Target UI patterns demonstrated

    1. Kanban ticket board (standalone Workshop application)
      • Separate columns/panels by ticket status.
      • Move tickets between statuses using an Update Ticket action.
      • “View details” opens an object view drawer without leaving the app.
    2. Object view for a single ticket
      • Built as a Workshop module embedded into an object view.
      • Includes an inline comment panel with:
        • object list showing comment history (sorted by creation time)
        • text input + submit button wired to an Add Comment action
        • success behavior configured (hide form, reset input)
      • Includes display refinements for long text using Markdown widget (for description).

  • Use-case documentation / solution design step

    • Before building, the speaker documents:
      • use case overview and solution design
      • functional requirements and the intended object model + ontology
      • lifecycle of elements and configured actions
    • Mentions public docs location for “use case lifecycle” (platform overview + use case lifecycle sections).

Implementation steps (what was built and how)

1) Data model: schema datasets (input/output backing)

  • For each object type, a schema-backed dataset is required.

  • Demonstrates two ways:

    • Quick approach via Fusion (spreadsheet-like editor) syncing a region to a dataset.
    • Production approach via code repository + PySpark transform:
      • creates ticket schema dataset for ticket properties
      • creates comment schema dataset for comment properties

  • Ticket schema fields (sample model)

    • creation time, created by
    • title, ticket id (string)
    • priority (int)
    • status (string / multiple choice later)
    • description (long text / string)
    • attachments (array of strings; later configured as attachment property type)
    • assignee (string)

  • Comment schema fields

    • creation time, created by
    • comment id
    • commenter (created by / commenter concept)
    • timestamp
    • comment text (string)
    • ticket id foreign key (comment relates to ticket)

  • Adds a correction during build:

    • Ticket schema initially forgot assignee, then added later via a commit + rebuild.

2) Ontology configuration: object types + links

  • Uses Ontology Management (OMA) to create/configure:
    • Ticket object type
    • Comment object type
  • Sets property mappings:
    • ticket title column as title key
    • ticket id column as primary key
  • Updates comment schema to include comment id so comments can have a proper primary key.
  • Creates a link type:
    • Comment → Ticket relationship uses comment’s ticket id foreign key matching ticket’s primary key.
  • Cardinality discussion:
    • Option to support many-to-many would require a mapping table dataset (not used in the simple model).

3) Property metadata & rendering hints

  • Configures how properties display and how they behave:
    • Timestamps formatted as short date/time or relative time.
    • Created by and assignee stored as multi-pass username and rendered as rich user identity (full name/email/profile lookup).
    • Description marked as long text; disables selectable/sortable/indexing hints to save index/storage.
    • Attachments changed to an attachment property type so file drop/upload UI and storage are handled automatically.

4) Write-back enablement (editability)

  • To support mutations via actions, the speaker creates writeback datasets:
    • generated output datasets for ticket and comment objects
    • used to materialize edits and enforce permissions

Action configuration (core behavior)

A) Create Ticket (action type)

  • “Change object” action that:

    • creates a new ticket object
    • sets creation time/current user automatically (not user-provided)
    • generates a ticket id using a UUID “magic incantation” in the form:
      • actions_generate_uuid (as described)
    • uses form elements:
      • ticket title (text)
      • description (textarea)
      • status (multi-choice)
      • priority (integer with min/max constraint)
      • assignee (dropdown over users via multi-pass usernames)
      • attachments (optional)

  • Security/submission criteria

    • Initially set to a specific external dev relations user; later demonstrates customizing conditions conceptually (e.g., restricting who can modify tickets).

B) Update Ticket (action type)

  • Another modify action that updates:

    • assignee
    • status
    • description (title sometimes editable depending on configuration; described as allowed)

  • Demonstrates:

    • status dropdown with static allowed values (backlog/active/complete/dscoped)
    • optional validation logic and potential override-based state transitions (not fully implemented; kept straightforward)

  • Adds validation/security example:

    • submission criteria can require “current user is the ticket assignee” (property-based logical conditions).

  • Status transition logging

    • Turns on logging for updates:
      • creates an additional “log object type”
      • each update execution creates a log record capturing:
        • timestamp, user, action type
        • values changed (title/assignee/priority/status)
    • Log objects link back to the ticket so the UI can show a timeline/history.

C) Add Comment (action type)

  • Creates comment objects with:
    • created by = current user
    • creation time = current time
    • ticket id automatically derived from context (ticket object passed as a form parameter)
    • comment text from a user input field
  • UUID generated for comment id; hidden from user.

UI build in Workshop

1) Ticket object view (single-ticket module)

  • Built a Workshop module inside an object view editor, using the object view editor only briefly, then switching to Workshop for modular flexibility.

  • Replaces default tabs with a Workshop module tab (“overview”).

  • Comment UI pattern:

    • collapsible “comments” panel
    • object list bound to an object set variable:
      • starts from “current object displayed in the object view”
      • filters comments related to that ticket
    • displayed comment properties:
      • comment text
      • created by (rich user rendering)
      • relative creation time
    • submit comment button executes Add Comment action
    • hides the form and applies immediately on valid submission
    • resets the comment input after successful action

  • Ticket details UI pattern:

    • description displayed via Markdown widget
    • layout reorganizes properties:
      • status/priority/assignee in columns
      • attachments deferred (not fully wired in the object view stage)

  • Finally:

    • save + publish object view + workshop module
    • verify via object explorer results and interaction with actions/comments/logs.

2) Standalone Ticket Kanban app (multi-ticket)

  • Creates a new Workshop application (not slate) called something like ticket kanban / ticket tool.

  • Layout:

    • panel/column per ticket status:
      • backlog, active, complete
      • dscoped linked via “view dscoped tickets” (opens object explorer rather than rendering all dscoped in board)

  • Data/UI wiring:

    • defines object set variables:
      • all tickets filtered by status values
    • each status section uses an object list showing key fields (status column often omitted since column implies status)
    • each list has an action button:
      • “edit/update ticket” uses Update Ticket action
      • passes the “active object” from that list as default ticket parameter

  • “Add new ticket”:

    • button triggers Create Ticket action
    • newly created tickets appear in the backlog or based on user-selected status.

  • Notes on runtime behavior:

    • mentions lack of push notifications; may require refresh or config for auto refresh
    • if another user changes a loaded object, user may be prompted to refresh.

3) Ticket details drawer inside kanban

  • Adds a right-side drawer containing the ticket object view component.
  • Uses events and variables to ensure correct selection:
    • “View details” button opens the drawer
    • a singleton variable (“object to display in object view”) is set based on the last selected object in whichever list (backlog/active/complete)
  • Disables auto-selection to avoid confusing defaults.
  • Demonstrates reuse of the object view module so users can:
    • see ticket details
    • add comments
    • modify the current ticket contextually within the Kanban app.

Key analysis/takeaways emphasized

  • Object Layer structure drives UI and behavior:
    • schema dataset → object type → properties metadata → link types → actions → writeback datasets → UI wiring.
  • Actions + permissions + submission criteria control who can create/update/modify workflows.
  • Logging via action execution enables later “meta analysis”:
    • timeline of status transitions
    • identification of bottlenecks / choke points in operational flows.
  • Workshop modularity:
    • object views can be composed from Workshop modules
    • the same module/view can be embedded in multiple apps (e.g., object view drawer inside Kanban).

Main speakers / sources

  • Primary speaker: Logan (referred to as “logan” and “future logan”)
  • Another speaker/source mentioned: “passlogan” (picks up after Logan’s preview)

Original video