It is important to take a step back from the Document Export query to determine the materials required for export, and how external systems need to consume the data associated with each material.
The Document Export query template is configured to return materials with an Export Value 1.
Adjust the Exports and Filters to return a different export value. This is helpful when setting up multiple document exports to different systems. See the Multiple External Systems section below.
Make it Match! If an index file exists, the Material Export export column must match with the Material Export filter (for example, Materials Export 1 always goes with Materials Export 1 Exists).
Multiple External Systems
If a material needs to be sent to additional external systems, use Export Values 2 - 5 for those document exports. For example:
When exporting multiple material types to the same system, the external system export values must use the same configuration across material types.
Exports for Document Generation
Remember that this is a document export, not a data export. Therefore, adding exports beyond the required items outlined on this page and those required by a document management system for the index file is not necessary. The pdf:file and pdf:xml exports are required, and are used to generate the documents in a document export. Do not change or remove these exports.
If a .tiff or .jpg file is required, replace the pdf:file export with a formula export. Name the formula export "pdf:file" and add the following snippet to match the schedule export document type:
'.' + (select q.[config].value('(p[k = "export_archive_type"]/v)',
'varchar(16)') from [query] q where ([id] = @query))
ImportantThese exports are required to generate the documents export file. Do not remove these exports. If you are not using an index file, these are the only necessary exports. If a custom pdf:file export name is required, refer to the Customizing Document Export File Names article for additional information.
Exports for the Index File
If an export is configured to generate an index file, all other exports will appear in that file.
If generating an index file, make sure that the query includes an export that can be used for matching criteria in the external system.
Include an export that contains a unique ID that exists in both the external system and Slate so the documents match the existing record. If the document export is the initial file entering the external systems, include the Application Slate GUID export to ensure that documents included in subsequent exports match the same record.
Adding Filters to Restrict Results
Like a Data Export, filters restrict the population of the results.
- Use filters associated with the Applications and Prospects query bases to define the application records that are included in the document export.
- Use filters associated with the Document Export (Application) query base to further restrict the materials that should be exported.
This filter configuration restricts the results of the query to only include materials with an export value 1 configured that are associated with applications in the active application period in an application round with the TR round key.
Adding Secondary Tracking Key
With document exports, you'll want to add a secondary tracking key for the material stream to ensure the query accurately produces the expected documents. Without this secondary tracking key, you may see all documents returned for each application rather than specific documents.
- In your query, click Edit Properties
- Under Secondary Key, add m.[steam] as the secondary tracking key
Adding this secondary key will tell Slate to track not only the applications included in the query but the specific documents as well. You should not add this secondary key to a document export that is already in use. This will cause all documents to be re-exported upon the next run. To effectively add a secondary key to an active document export, you should take the following steps.
- Create a copy of the query
- In the copied query, add the secondary key following the instructions above
- In the copied query, remove the row limit temporarily
- Run the copied query once to create a single "catch-up" query run of previously exported documents
- Restore the row limit in the copied query to ensure document export file sizes remain manageable.
- In the original query, export the documents to SFTP to ensure all documents have been exported; note, you may need to run the original query multiple times if the number of documents exceeds the query row limit. you may run this query to SFTP until running it produces no results
- Deactivate the Schedule Export on the original query
- Activate the Schedule Export on the copied query
- You may now archive the original query and continue using the copy moving forward