ZMongo Content Pack Export Static Workflow V3

Normal content packs are data: the values live in the pack, and you use Get nodes to pull them out. Export Static Workflow is the other strategy - it converts a pack into a workflow file where the values are already unpacked into a node with 64 output sockets, ready to wire directly into your graph. Think of it as baking the content pack into the workflow itself. Open the exported .workflow.json and the values are just there, no loading step.

How it works

The node takes your ZMONGO_CONTENT_PACK, flattens it into a compact "static values pack" (first 64 fields, in output order, aliases sanitized), then wraps that in a LiteGraph workflow JSON that contains a single ZMongo Content Pack Static Outputs V3 node with the values embedded as its values_json. Because it's an output node (is_output_node: true), running it surfaces the result in the UI, and the companion JS handles the rest - renaming and re-typing the node's 64 output sockets to match the fields, and offering to download the file.

Inputs are minimal:

• content_pack - what you're freezing.
• workflow_filename_prefix - the file's name stem (default content_pack_static_workflow).
• node_title - the title the embedded node gets (default "📦 Static Content Pack Outputs").
• pretty_json - keep the file readable, leave it on.
• browser_download - when true, the frontend auto-triggers a download of the .workflow.json after each run. Off if you'd rather only download on demand (there's a button for it).

Outputs

workflow_json (STRING) is the exported workflow you can save/forward, flat_pack_json is the embedded static values pack in its raw form, filename is what the download will be called, success is your flag, and refresh is the dirty token. The download goes through the browser via the JS - so if you're running headless, watch the workflow_json output instead.

When to use it vs. the normal path

This is for the "I want the workflow itself to be the archive" use case. Someone opens your exported file and immediately has the values as sockets - no session, no database, no loader node needed on their end (beyond having the pack installed so the node class exists). The trade is rigidity: the values are frozen at export time, so it's a snapshot, not a live database read. For anything that changes often, keep using Save/Load against the database. For a deliverable or a template you want to hand around, this is the one.