Hi Rachel, I checked our Jean-Paul AI solutions and found these options. Please let me know if any of these work for you. Best. Options, roughly best-to-worst: 1. Feed it a schema file instead of typing it. The Fixed-Width Parser Snap accepts a field description document (the layout as a document: field name, start position, length, type) rather than manually entering rows in the UI. If your customer already has a copybook, DDE, or COBOL layout for this file (very common source for fixed-width in the first place), that layout can usually be converted programmatically into the JSON schema the Snap expects — once, with a script — instead of clicked in by hand. 2. Generate the schema with a Script/Python Snap upstream. Have the customer keep their field layout as a simple CSV (name, start, length) — they almost certainly already have this doc somewhere, nobody hand-builds a 1000-field fixed-width spec from memory. Feed that CSV into a small Python Snap that emits the Fixed-Width Parser's schema JSON. Wire that schema in via pipeline parameter/expression instead of the static UI editor. Write once, reuse for every file variant. 3. Skip the Fixed-Width Parser entirely for very wide files. At "hundreds to thousands of fields," a lot of people just do the substring slicing in a Script Snap (Python) directly — read the layout CSV, slice each line by position, emit a doc. More code, but for 1000+ fields it's often faster to build and easier to maintain than fighting a UI-driven Snap's schema editor. 4. JSON Generator / Mapper trick: build the schema as a JSON array (name/offset/length) as pipeline data, then use an expression to pass it into the Parser's schema field dynamically — this is the "make the Snap itself more dynamic" ask specifically. Works if the customer's layout changes per file/feed and they don't want to hand-edit the Snap every time.
