Workshop: How do I save the filter output in an Object Type?

[cedarchase]

Here is my Workshop workflow: A user does a filter in the filter widget, they click a button, I want to create an object that stores what filter they have and ideally be able to reapply / reload that filter at a later date. How would I build this out? For example, I can’t even do the first part, of getting the filter output into a string or something to store on the new object that gets created.

Example of what my filter output looks like. But what “Type” is this?

{
  "and": {
    "filters": [
      {
        "or": {
          "filters": [
            {
              "exactMatch": {
                "terms": [
                  "flight"
                ],
                "propertyId": "type"
              },
              "type": "exactMatch"
            }
          ]
        },
        "type": "or"
      }
    ]
  },
  "type": "and"
}

Cus I think if I could store this in an object type. Then later in my workflow if the user want to reload this object with it’s filter, they can, since I can just pass this filter back into an object set to filter on it.

[bkaplan]

I don’t believe this is currently possible, but there are a few possible workarounds depending on what you are trying to do exactly.

1. Workshop Native State Saving - workshop has the concept of state saving where you can select variables to save there state including filter lists
2. Filter List Set Variable value - you can add a default value to a filer list and set it to update that variable when users update this. You can then save these array of strings (or other types) into an object as a property. This does not scale wonderfully, but can work well if you are just trying to save a few properties

Curious to hear more about your specific use case and if these solutions might work for you.

[Phil-M]

Hi @cedarchase There is a third option that actually allows you to extract the stringified filter text, save it as a string on an OT and read it back to an object set filter. This is way more cumbersome option, but also very powerful and allows a lot user customization for things like bookmarking. I am still hopeful that PD has a simpler way of extracting this information on their roadmap since they mentioned it in the past.

https://community.palantir.com/t/enable-saving-of-object-set-filters-in-workshop/2653/6?u=phil-m

[cedarchase]

Thank you both. I ended up going with the Filter List Set Variable Value option. It’s not ideal since 1) I have to set defaults for all filters (and it’s doesn’t include the relative date filter) and 2) I can’t rerun these filters at a later date. But for now, at least I can store the filter that was used (excluding relative dates) for auditing in my Object Type and I can generate a LLM summary of the filters to show in the UX for the user (to recreate at a later date if needed). Below is more detail on my use case.

My Use Case
I have a shopping cart-style workflow where:

• Users apply filters to Employee data and add items to their cart
• The cart is deduped to get unique Employees
• Days later, colleagues need to re-run the exact same filters to check for changes
• We need audit trails showing what filters were applied to generate each output list

The key requirements are:

• Persistence: Filters must be stored long-term as auditable records
• Shareability: Multiple users need to access saved filters
• Reusability: Saved filters must be reloadable into Workshop

Evaluation of Current Options
Workshop State Saving: This partially works but has limitations for our needs:

• States are saved in Compass, requiring users to leave Workshop to find a colleague’s saved filters
• Not auditable as an Object Type - we’d have to manually search through saved states
• Doesn’t integrate well with our existing audit trail workflows

Filter List Set Variable Value: This is what I initially considered, but it has significant limitations mentioned above.

Slate Option: While clever, I agree with Phil-M that it’s cumbersome:

• High maintenance burden for long-term support
• Risk of breaking changes
• Not something I want our team to maintain

Potential Feature Requests
Option 1: Native Filter Serialization

• Add a Workshop function to convert Object Set Filter → String (JSON)
• Add a corresponding function to convert String (JSON) → Object Set Filter
• This would allow storing filters as string properties on Object Types

Option 2: Object Set Filter as Object Type Property

• Support Object Set Filter as a native property type on Object Types
• Allow reading/writing these filters directly from Workshop

Option 3: Allow Object Set Filters as a type for typescript functions

• This would allow us to pass the JSON into a function and return it as a string.

[Phil-M]

Hi @cedarchase I resonate with your pain and 100% agree with FR option 1 (serialization).

Out of curiosity, on your current implementation you have a property for every filter property you want to store or are you converting it into one generic custom json string variable?

[cedarchase]

Hey @Phil-M , I’m just concatenating all the variables and then passing them to a Typescript function to summaries what the filter was using a LLM. Then i’m showing that output in the UX so the users have a summary of the filters applied. I won’t be able to re-create the filters, but for now that will suffice. Below are some screenshots.

The filter output has all these defaults:

And you have to have that toggle at the bottom enabled. So when users add filters, the variables update.

Then I concatenate those variables in Workshop and pass them into a TS function that summarizes the filters. The TS function looks something like this:

@Function()
@Uses({ queries: [LLMService.createCompletion] })
private async generateSummary(
    method: string,
    data: string
): Promise<string> {
    const prompt = `Create a concise summary based on:
    Method: ${method}
    Data: ${data}
    
    Generate summary:`;

    const params = {
        temperature: 0.3,
        maxTokens: 50
    };

    try {
        const result = await LLMService.createCompletion({ prompt, params });
        
        if (result.type === "error") {
            throw new Error(`API error: ${result.error}`);
        }
        
        const response = result as any;
        return response.value?.completion?.trim() || `${method}: ${data}`;
        
    } catch (error) {
        console.error(`Failed to generate summary:`, error);
        return `${method}: ${data}`; // Fallback
    }
}