Job Administration Features
The CopiaFacts Job Administration option has been designed to assist users in a wide variety of application areas, and to support many different styles in which broadcast jobs can be implemented.
This section provides a summary of the features incorporated in 'Job Administration'.
Client Data Management
A set of 'owner properties' is maintained for each entity for whom the system runs broadcasts. Typically the Owner level would represent a service bureau client, and the properties define default values for the jobs which the system will run for that particular client.
Above 'owner properties', 'system properties' can be defined as defaults for all owners.
Below 'owner properties', optional 'job type properties' define defaults for specific types of job to be run for the client. For example, separate job types could be defined for fax broadcasts and voice broadcasts. Job types can also be used to specify different sets of recipient lists to be used.
At all levels, property sets can be extended by defining custom user variables which can be used to customize broadcasts.
The provided JOBADMIN program can be used to edit all levels of these properties. In addition, a Job Administration application program interface (API) is available which can be used to edit properties from custom applications.
When a specific instance of a job is created for transmission, properties are first combined from the system, owner and jobtype levels. Then the job instance properties can be set with the specific documents, broadcast list, priority and other options either not specified as defaults or required to be overridden for the specific job instance. Each job instance has a unique reference number (which can be set to be from 5 to 8 digits) which is associated with all aspects of the job.
The Job Administration API is used by the interactive voice response (IVR) Job Administration option, which allows a caller to set up job instance properties, and select lists, prior to the launching of a job instance for transmission.
Lists of Broadcast Recipients
The system can accept recipient lists in a variety of different formats. Standard ASCII lists are the simplest, and within them fields can be delimited either by tab characters or by another standard delimiter character. Excel spreadsheets can also be used directly, as can DBF format files. Most database applications allow data to be extracted for a broadcast in at least one, if not all, of these formats. Because users normally prefer to maintain their own recipient list data, the Job Administration system does not force this data to be maintained within the CopiaFacts system. This allows users to handle both applications where the bureau client provides the list and those where the bureau itself manages the lists.
By default, XLS and XLSX files are read directly using a library implemented in CF8EXCEL.DLL, and Excel is not required to be installed. However the following important considerations apply to these files:
•XLS files produced from Excel 95 or earlier are not supported by the internal XLS reader and require Excel. The USE_EXCEL control variable must be set to a non-empty value.
•XLS and XLSX files with very complex formulas may require Excel, in which case the USE_EXCEL control variable must be set to a non-empty value.
•When USE_EXCEL is specified, XLS and XLSX files require Excel 2007/2010/2013/2016 to be installed.
•The internal XLS reader is implemented in CF8EXCEL.DLL for CopiaFacts version 8.1. This also supports XLSX files and is used by default, if it is not found, Excel will be used and is required.
The only requirement for a broadcast list is that it should supply the destination for each broadcast item, such as fax number, phone number or e-mail address. But additional list columns are made available to be used to customize broadcast items before transmission.
Any broadcast job can use multiple lists provided that the columns required for the broadcast are in the same positions in each list. You can specify whether or not lists have header rows.
The data from the first item in the first list will be used when a 'proof' or 'preview' of the broadcast is requested as described further below. An override number or e-mail address can also be supplied so that the proof fax or e-mail is not actually sent to the destination specified in this item.
Job Administration supports three different types of broadcast destination: fax machine, telephone and e-mail mailbox. However these are extended to six different broadcast types, because in addition to normal outbound broadcast, a fax machine can also be called (polled) to cause it to transmit a document to the system; and two additional broadcast types support combining fax and e-mail destinations within a single broadcast.
Broadcast destinations in a provided list can be filtered to prevent unwanted transmissions from being made. There are facilities to define 'do-not-send' look-up files for specific owners as well as for global use by all owners. Destinations can be looked up in one or both of these indexed lists. Separate indexes are available for fax and telephone numbers, e-mail addresses, and e-mail domains, and the do-not-send look-up data can be provided either as a simple dBase NDX file, or in a SQL database.
There is an option to filter out grossly malformed or blank destination fields before the broadcast job is launched, and such items are omitted from job reports. This is sometimes necessary if the lists are not under the control of the broadcast service bureau.
There is also a Job Admin option to 'de-dupe' the list or lists for a job prior to launch. This can either operate on a single destination column of the list, or can be combined with any other column or columns such as the recipients name. The latter feature would be needed if a list is expected to include sets of different names for the same destination fax number.
The basic source document for a fax broadcast is a pre-prepared faxable TIF file. Such files can be created manually by means of the CopiaFacts 'Fax Save' printer driver. When no customization is needed, one or more of these files can simply be specified as the master document(s) for a fax broadcast job.
With the Job Administration IVR option, the client can call in to the system and fax in a master document before launching the broadcast. The owner properties can specify that a proof fax-back is to be done before the client calls back to confirm that the broadcast is to be launched. Alternatively the job can be set to launch automatically in the absence of a call to cancel it.
Simple Fax Customization
Data from the broadcast list column can be used to customize outbound faxes. At its simplest, identification data such as the recipient's name can be placed in the fax header line. Although cover sheets are not normally used for broadcasts, one can be specified using graphical customization to place any available item or job data on the cover sheet.
With the Job Administration IVR option, the faxed-in document can be used as the graphical customization 'watermark' file, and variable overlays containing item or job data can be laid over the master faxed in document.
Finally, there is an option to provide a multi-page graphical customization template as a coversheet which can be overlaid, with different page headings for first and continuation pages, over the faxable TIF files comprising the broadcast. It is not necessary to pre-specify the number of pages because the continuation page header will be repeated as required.
The basic content for an e-mail broadcast consists of body text and headers such as 'subject'. Body text for a broadcast is usually supplied in a TXT or HTML file. When HTML text is included in a broadcast it is usual to provide a plain text body and an HTML alternate body, which allows recipients to read the content even if their mail client software does not support HTML e-mail.
Transmitted e-mails contain standard headers, all of which can be customized, and non-standard headers can be added if required, again fully customizable.
Variables included in the body text and the headers are expanded using any available job or item data.
Control is provided over the character set of the body text and headers, and non-ASCII characters such as accented letters are automatically encoded as quoted-printable.
MHTML e-mail is fully supported, and images embedded in messages can be linked to attachments specified as part of the message.
Attachment files can be specified for an e-mail broadcast, along with the content-type which is to be applied. There is control over the filename of the document which is seen by the recipient, which need not match the actual filename on the CopiaFacts machine.
There is an option to expand variables in HTML attachments in addition to the expansion of variables in body text.
When an attachment document is specified as a faxable TIF file, the system can handle conversion to PDF, PNG, JPG or GIF format prior to transmission, depending on the content-type specified for the document.
Individual broadcast jobs can be transmitted using different local machine IP addresses and adapter bindings on a suitably configured node running CopiaFacts software.
Combined Fax and E-Mail broadcasts
Broadcasts can be transmitted to a list containing both fax numbers and e-mail addresses. The list can be set up with a single 'destination' column so that each recipient can receive the broadcast by one method; or separate columns can be supplied for fax numbers and e-mail addresses and a second method will be used, if specified, only if the first one fails. The first method is recommended.
In fax attempts, the system ignores any e-mail properties specified for the broadcast, and vice-versa.
Either separate documents can be sent for fax and e-mail transmissions, or the same document can be sent. TIF documents to be faxed and e-mailed can either be e-mailed in TIF format, or in PDF or another supported image format. Documents which are converted from other formats for faxing can be e-mailed in the original format or as a TIF, PDF or other supported image format.
For recipients for whom both fax number and e-mail address is available, the default is to attempt e-mail first, and then fax if that is unsuccessful: this normally minimizes the cost of transmission. However an option is available to attempt the fax first and the e-mail if that fails: this normally maximizes the success rate.
Job Administration is integrated with the CopiaFacts Document Converter feature and their is an option to allow the pre-conversion of documents in formats such as Adobe PDF, Microsoft Office DOC, PPT and XLS, and HTML formats. This allows a single conversion to be made before the job is launched.
In an HTML original document, there is an option to expand CopiaFacts variables in the text before conversion. If any per-item variables such as list column variables are found, pre-conversion is suppressed and individual conversions are performed for each job item.
Items to be pre-converted are given high priority in the Document Converter so that they are not queued behind other high volume conversion tasks. This feature requires MSMQ2 to be installed in Windows, so is only available in Windows 2000 and later.
For jobs which have a complex sequence of conversions or customization it is useful to be able to preview the result. Job Admin allows any fax job output to be previewed, creating a single faxable TIF file which contains the data from the first item in the first list of the job. This can be made available via the a user-written web application. In addition to a TIF preview, the output can also be created as PDF or one of the supported image formats such as PNG.
A 'fax header line' can also be added to a preview image. Because such a header line is normally only added at the last minute when a real fax is transmitted, this preview header line emulates a 'real' fax header.
Items to be previewed are given high priority in the Document Converter (if applicable) so that they are not queued behind other high volume conversion tasks. This feature requires MSMQ2 to be installed in Windows, so is only available in Windows 2000 and later. In addition the CopiaFacts engine can process a preview on any available free line, so as to minimize the delay in making a preview image available for viewing.
An optional extension to the Job Administration feature allows fax broadcast jobs to be submitted remotely. In this scenario, the bureau client calls in to the CopiaFacts system, authenticates himself using DTMF (touch-tone) responses to voice prompts, selects the lists to be used in the same way, and finally faxes-in the broadcast master on the same call.
Normally such jobs are set up to first send a proof back to the submitter, and then either to launch if not canceled within a specific time period or require another voice call using IVR to confirm the launch.
The interactive session is fully customizable using standard CopiaFacts IVR capabilities. For example additional questions can be included to allow selection of an alternate proof number, a non-standard priority setting, or a delayed launch of the job.
Standard voice prompts are provided for all the basic job administration IVR messages. In addition users may supply additional voice descriptions, for example containing the spoken name of each selectable list, so that a confirmation message can be played after a list has been selected.
CopiaFacts job administration has a Word Merge option which accepts a job consisting of a normal 'Word merge to print' and causes it to be transmitted by fax or by e-mail, using Microsoft Word to render a customized document for each recipient. This requires both a master document containing named merge fields and one or more lists containing matching column names in one of the formats supported by CopiaFacts.
This option provides a convenient method for bureau clients to prepare broadcasts, but it is resource-hungry for the bureau to process it, because it requires a Word print operation (to the Document Converter print driver) for each recipient. It also requires Word on the machine which processes job launches, because we use Word automation to remove the original data source from the job document.
The Word Merge output for e-mail recipients can be a copy of the individually customized Word document, a customized TIF as would have been faxed, or a PDF or other supported image format converted from the TIF.
The minimum data requirements for a voice broadcast consist of a broadcast list and a voice message to be transmitted. The job normally specifies a CopiaFacts infobox (.IIF file) which identifies the voice message file to be played. Standard infobox logic can be used to customize the broadcast, for example by selecting the message based on data in list columns other than the telephone number.
A voice broadcast is not limited to playing a single message. Multiple messages and prompts can be played, and the broadcast can lead in to an IVR session in which the called party is asked to make selections or interact in other ways.
The job administration IVR option can be customized to allow the caller, after identification and list selection, to record the actual message which is to be broadcast. This can then be included in a test call to the 'proof' telephone number in the same way that a fax broadcast proof is transmitted for verification before the broadcast is launched.
For use with fax boards for which CopiaFacts supports fax polling, broadcast jobs can be set up in which each specified fax machine is called (polled) to retrieve a fax which is prepared for transmission.
An extensive application program interface (API) is provided for customers who wish to integrate job administration into their own applications or web services. Almost all of the features described above can be initiated and/or monitored using API functions.
The API is implemented in a standard Windows DLL which can be called directly from most application development environments. Additional interface DLLs and samples are provided to demonstrate how to access the API from Visual Basic and .NET applications.
Full documentation is provided for all of the API functions, parameters, and error returns. However we recommend that customers proposing to use the API should first contact Copia support for specific guidance on their applications.
Data can be extracted for reporting in XLSX, DBF or tab-separated-value format.