New RPM 7 Beta is now available — try the new release →

Transforms and Metadata

You’ve already seen how transforms fit into the processing pipeline — they run in sequence, and their combined output feeds whatever actions a queue defines. This page is about something narrower but genuinely useful: metadata, and one specific transform built entirely around it.

What Metadata Actually Is

Metadata is everything RPM knows about a job besides the job’s actual contents. Some of it arrives automatically — LPD, for instance, hands over the job name, filename, an optional title, and the sending host’s self-reported name, all without any configuration on your part. The rest, you can generate yourself, from the job’s own contents, using the Data Extraction transform below.

Where Metadata Gets Used

Metadata isn’t just informational — several actions and transforms can reference it directly:

  • Filter action and transforms — metadata values can be used directly in a command line.
  • Email action — metadata can populate the subject line.
  • Archive action — depends on metadata to construct the output filename.
  • Copy Queue action — can use metadata to decide which queue a job gets copied to (more on this below).

Pulling Metadata Out of a Job — Data Extraction

If the information you want isn’t handed to you automatically, the Data Extraction transform lets you pull it straight out of the job’s own contents:

  • Specify a line, column, and width to grab a fixed-position value — or use a regular expression if the data isn’t in a predictable fixed spot.
  • Choose which metadata tag the extracted value populates.

Like every transform, Data Extraction only reads the job — it never modifies the data itself. We’d suggest using it alone in a transform sequence rather than mixing it with other transforms, mainly to keep troubleshooting simple: if something’s not populating the way you expect, you want to know it’s the extraction step and nothing else. Remember that transforms run before actions, so whatever tag you populate here is what your actions will reference afterward.

Routing Jobs by Their Own Content — Dynamic Copy Queue

Metadata can do more than fill in a filename or a subject line — it can decide where a job goes next. In the Copy Queue action’s setup, turning on the Dynamic queue toggle and selecting a metadata tag lets RPM route a job to a different destination queue based on something pulled straight out of the job itself — a destination email address extracted from the page, say, or a document name that determines which downstream process should handle it.

This is a genuinely different capability than static queue configuration: instead of every job on a queue going through the same fixed set of actions, the job’s own content can determine its path.