Naming and keeping track of jobs that have been imposed

Post Reply
wwstudios
Member
Posts: 20
Joined: Tue Mar 12, 2024 7:29 pm

Naming and keeping track of jobs that have been imposed

Post by wwstudios »

What method do you guys recommend for naming and keeping a log of what jobs go into an imposed layout?

Right now we have been moving away from manual setups and doing more with Switch and Griffin Auto.

However, the layouts that come out of Griffin I have named with a date and the 5-digit identifier Switch generates.

This has caused some (admittedly justified) complaining from people in the shop.

Before, they had:

29806 - Acme Co. Name Tags.pdf

and

29806 - Acme Co. Name Tags-CUT.pdf



but now with things moving through Griffin they have:


Plastic-Name-Tag-Layout-2025-06-25-05UTN.pdf

and

Plastic-Name-Tag-Layout-2025-06-25-05UTN-CUT.pdf



I can understand why they would like a more readable naming convention.

However, it's hard to do this because now with Griffin it imposes all different tags and items from multiple jobs. Rarely is a layout ever just from one customer anymore.

Also this does make it more difficult to go back and see what job was printed when. I can't really search for them.

I was thinking of grabbing job names from the files submitted to the Switch imposition flow and adding them to private data, then throwing on into the filename just so they have something to go on.

Is there a best practice in this case?

Thanks for any help!
User avatar
magnussandstrom
Advanced member
Posts: 512
Joined: Thu Jul 30, 2020 6:34 pm
Location: Sweden
Contact:

Re: Naming and keeping track of jobs that have been imposed

Post by magnussandstrom »

It sounds like it might be a good idea to take a step back and rethink the workflow. Software delivers the best results when you first sketch out the workflow you want, before building it in Switch. A great starting point is to involve the press operators and ask what information they need in the file names or logs to do their jobs effectively.

Often, the best approach is to ”sketch the workflow in reverse”, start by defining the end result you want (for example, file names, imposition summary, logs, traceability) and then work backwards to see how that information can be collected and carried through the entire flow.

There are many possible ways to solve this issue, but it’s hard to give specific advice because your problem description is a bit too vague.

What information do the operators really need to see in the file name?

What information could instead live in logs or production systems?

Do you need to track individual jobs, combined layouts, or both?

Once you have clarified your needs, you can build a Switch flow that strikes the right balance between automation and clarity for your team.
Post Reply