APOGEE Network
APOGEE > WebAprroval Self-Service Job Ticket Creation
Related

Self-Service Job Ticket Creation

At A Glance:

WebApproval's Self-Service feature is based on Agfa Apogee Prepress Job Ticket Templates that are "published" for external customers to select when initiating their jobs in the PageMaster interface. This module discusses various considerations in preparing the tickets.

Applies To:

:Apogee WebApproval

How It Works:

The heart of Self-Service is making job ticket templates available for your customers to select when creating their jobs. You will be creating a separate set of tickets for Self-Service from your normal production tickets because of certain constraints and policies that must be followed for the feature to work correctly.

Definitions

Before discussing the ticket creation itself it is important to identify some new terms.

Customer Setup In terms of Self-Service, Customer Setup refers to a customer's ability to modify the number of parts and the page count of a job. You can choose to allow your customer to modify this specification when they create a new Self-Service job or you can force them to accept the parts and page count of the ticket they selected.
Printer Setup Since the customer, not the prepress department, initiates Self-Service jobs, it is important that the print shop have the ability to review the job and make any production modifications necessary. This includes, but is not limited to, order number, job name, product definition, imposition, separations and press.
Customer Setup Complete An indication that the customer has finished modifying the parts and page counts and that the job is ready to start production. Customer setup is usually finalized by the customer after they initiate the Self-Service job. However, the job ticket template can be saved as "Customer Setup Complete" to prevent customers from modifying the job structure. The print shop also has the ability to change the status of a new Self-Service job to "complete" in the event the customer did not. Printer Setup cannot be finalized until the customer setup is done.
Printer Setup Complete An indication that the print shop has finalized the production aspects of the Self-Service job and accepted the order. While a customer may upload, preflight and softproof pages at any stage during the setup process, they may not make page approvals until the printer setup is complete.


Job Plan Structure

The actual job plan creation is straightforward and very similar to a traditional WebApproval job. However, there are two acceptable methods for branching the web proof flow and placing the Web Proof action: either before the Run List or after it.
Before we discuss why you would choose one versus another, you need to understand that the branch spot and Web Proof action work together and both must be properly positioned for the Self-Service ticket to work properly.
When branching the web proof flow before the Run List, you need to position the Web Proof action immediately after the Run List.
Apogee Prepress Flow Branch Before Runlist

When branching the web proof flow after the Run List, you need to position the Web Proof action before the Display task processor.
Apogee Prepress Flow Branch After Runlist


Rationale

The decision to branch the web proof flow either before or after the Run List depends on the way in which your customer works with their files and the way that you intend to handle the set-up of Self-Service jobs.
Branching before the Run List immediately processes uploaded documents through the job ticket's web proof flow. This allows your customer to see both Flipbook/Preview and StreamProof data within the Uploaded Documents drawer before the pages are placed in the Run List. This behavior is comparable to the proofing offered by other services like Kodak InSite.
WebApproval Result Branching Before RunList

Branching after the Run List allows customers to view only the native preflighted PDF until the pages are placed in the Run List and processed by the web proof flow of the job ticket. This is the classic WebApproval behavior.
WebApproval Result Branching After RunList

Regardless of where you branch the flow, preflight data, if available/allowed, is available immediately.
There are limitations to both methodologies. You should test a few jobs using both styles to find out which is appropriate for your customers and their workstyle.

Branched Before the Run List Branched After the Run List
StreamProof and Flipbook are available on individual documents which are not yet assigned to the Run List. Only PDF Softproof is available to documents not assigned a Run List position.
Rasterized proofs are generated BEFORE printer setup is complete. Rasterized proofs generated only AFTER printer setup is complete.
Rasterized proofs are initially generated according to ticket template parameters. Changes to the web proof flow parameters after the job is created will cause reprocessing. Rasterized proofs are based on the production flow.
Not appropriate for Versioning or multiple Production Sets. Versioning and multiple Production Sets are supported.

Note: When branching before the Run List, the rasterized proofing data is generated according to the ticket template settings. If the proofing flow is based on the production parameters and they change during printer setup, the web proofs will reprocess. To avoid this, you could hard set unique proofing parameters, but bear in mind that if the customer's content is not appropriate for those values the proofs may not be accurate.



Agreements

There are also a few rules regarding Self-Service that you need to understand.

  1. Regardless of the proof data available, page approval or rejection is only applicable to content in the Run List (e.g. - assigned to an actual page position in the job). This is true regardless of where the flow is branched. There is no way to approve pages in the Uploaded Documents drawer.
    Approval and Rejection Buttons in WebApproval
  2. Printer setup must be completed before any approvals or rejections can be made. The customer is reminded of this in the orange dialog box at the top of the Pages area.
    Waiting for the printer to finish the product setup
  3. Customer setup can remain incomplete and they can place pages in the Run List before it is finalized. However, printer setup cannot complete until the customer set up is complete. Customer setup can be overridden by the print shop in the :Apogee Prepress client.
  4. Ready to Inspect ( Ready to Inspect button ) means only that proofing data is available and that the page has not been approved or rejected. Whether a page can be approved or rejected depends on the status of the job in the production process and its presence in the run list.
  5. The Jobs Overview or the Job Status pane shows how many pages are actually waiting for approval.
    Job Information Area in WebApproval



Publishing Your Job Ticket Templates

Once you have created your job plan, you'll need to save it as a job ticket template and enable it for Self-Service.
Be sure to test each ticket template you create for the Self-Service workflow before your customers use them for production to make sure they behave as expected.
Template settings in Apogee Prepress for WebAprroval
Note: When working with ticket templates in :Apogee Prepress 7, you may notice some new icons next to the ticket names:
Indication that there are WebApproval components in the Apogee Prepress jobindicates that there are WebApproval components in the job plan.
Indication that the Ticket Template is enabled for Self-Service jobsindicates that the ticket template is enabled for Self-Service jobs.

Name Is the internal name for the ticket template in :Apogee Prepress.
Description Is the text that internal users will see when opening a new job in :Apogee Prepress.
Enable Use by Portal Allows the ticket to be used by Portal PageMaster customers.
Visible to... You can choose whether this ticket can be seen by all customers who have permission to use Self-Service or just one. To restrict this ticket to a single customer, add their WebApproval account to the Customer Contact section of the Administration tab and select the second radio button.
Name for Customers The template name customers will see in Portal. It can be different than the internal name.
Description for Customers The description customers will see in Portal. It can be different that the internal description.
Customer Setup Complete Check this box to prevent a customer from changing the format of the job.
Printer Setup Complete Checking this box indicates that the template is finalized and will allow customers to create jobs and begin making approvals without further interaction by the print shop. Caution: Changing processing parameters after the printer setup is complete may cause the web proofs to reprocess.


Scenarios

Now that we've reviewed the technical aspects of creating ticket templates for Self-Service, let's take a look at a few practical applications for the various types of work you may encounter.

General Commercial Since this work is "never the same job twice," it's difficult to know in advance the number of colors, parts or pages in the job. Because of this, you'd probably want to have the template fairly open with regards to processing restrictions and you'd likely only proof once you were certain you knew all of the job parameters.
Proof flow branch After Run List
Customer Setup Left unfinalized in template
Printer Setup Left unfinalized in template
Result Customer would modify job format as necessary and finalize setup. Pages could be uploaded and placed immediately, but raster proofs and approvals would not be available until the printer setup was complete. The proofs would accurately reflect the production processing.
Designer & Editor In this scenario a designer is responsible for providing content, but not necessarily responsible for the approval. What would likely be important here would be for the designer to see proofs and to be able to get feedback from others associated with the job early in the process.
Proof flow branch Before Run List
Customer Setup Left unfinalized in template
Printer Setup Left unfinalized in template
Result Designer or Editor would modify job format as necessary and finalize setup. Raster proofs/preflighting would be available immediately. Approvals would not be available until the printer setup was complete. The proofing parameters would be set independently of the actual production flow meaning that there might be minor inaccuracies in color handling (e.g. - proof = keep spot colors, production = convert)
Magazine In a publication there is the benefit of repeatability, especially in color separations. By leaving the imposition undefined and basing the proofing flow on the production flow, both proofs and approvals would be immediately available. The imposition could be modified after the fact with no impact to the proofs.
Proof flow branch After Run List
Customer Setup Left unfinalized in template
Printer Setup Marked complete in template
Result Customer would start the job, modify page counts and finalize the format. Proofs and approvals would be immediately available and accurate to the production flow.
Sell Sheets Any collateral/campaign items that have common production considerations can be processed quickly in a Self-Service environment. If, for example, you have a customer that is producing a series of 4 page, 2 color brochures, you could lock the template down completely including spot color and imposition. Don't forget that you can limit a template to a single customer, which in this example may be important to do.
Proof flow branch After Run List
Customer Setup Marked complete in template
Printer Setup Marked complete in template
Result Customer would start the job and immediately begin uploading. There would be no setups to finalize either externally or internally. Production accurate proofs would be immediately available.

Why is this Important?

The Self-Service job creation feature in WebApproval is very flexible and powerful. It takes the familiar concept of job ticket templates and allows you to leverage them with your customers. Learning the parameters and constraints of deploying the templates is key to the success of this feature.