> ## Documentation Index > Fetch the complete documentation index at: https://docs.insight.nobly.dk/llms.txt > Use this file to discover all available pages before exploring further. # Try, check and publish a mapping > Run sample documents through a draft mapping, check it against Nobly Insight before anything is uploaded, publish it, and use it in a workflow. A [document mapping](/contentflow/document-mappings) is worth testing in three ways before workflows run it. **Try it** shows what a sample document becomes. **Check against Nobly Insight** shows whether the destination accepts that result. A [workflow test](/contentflow/testing-workflows) then runs the whole pipeline on the draft. ## Prerequisites You need `mappers.view` to try and check a mapping, and `mappers.manage` to publish it or restore a version. Expression rows only run in Try it if you hold `mappers.manage` or `workflows.manage`; see [Expression rows](#expression-rows). ## Try a sample document The **Try it** tab at the bottom of the editor runs a sample through the draft as it is on screen, on every edit. Nothing is saved, and nothing is sent to Nobly Insight. Paste a sample into the text box and choose **Load properties**. You can paste the document payload of a run from [States](/contentflow/states-and-recovery), the body of a submission, or `Name=Value` lines. Property groups, the sender's document type, and its date are kept. **Add the properties this mapping reads** adds an empty row for each property the mapping uses. Edit, add or clear properties in the sample table. When the document type or date comes from the sender, fields for those values appear as well. **Document Nobly Insight receives** lists the document type, the document date and every keyword, each with the reason it got its value. The rule that matched is flagged in the document type section. Select a keyword to jump to its row. Document Nobly Insight receives: document type Policy document from rule Policy schedules and terms, a document date from Created, and keywords such as Customer number 00004471 from CustomerNo and Sensitivity Internal from Confidentiality INTERNAL via row 2, followed by one field not written and a note that SourceRef came in but no rule or row reads it The result also shows: * **Fields not written**, each with the reason. A reason can be that the incoming property is empty, or that the row does not apply to this document type. * Incoming properties that **no rule or row reads**. With pass-through off, nothing of them is sent. Check this list for a property that the sender renamed. * **This document would stop before upload** when a row's empty policy, a validation, or the document type rules stop the document. In a workflow, the run then fails with that explanation, and nothing is sent. Test more than the happy path. Try a sample with a missing mandatory value, an unknown code for each lookup, and one sample per document type your rules can produce. ### Expression rows An expression row runs C# code with the environment's identity, and it can read secret global variables. For that reason, expression rows are only evaluated in Try it for people who may already put code into live runs: holders of `mappers.manage` or `workflows.manage`. For anyone else, the result notes that expression rows were not evaluated, and those rows show as stopped. ## Check against Nobly Insight Below the result, **Check against Nobly Insight** compares the mapping with what Nobly Insight reports for a document type, before any upload is tried. Leave **Document type** empty to check the type your sample resolved, or enter another type. Then choose **Check**. Check against Nobly Insight result for Claim correspondence, with a summary saying two things need attention and a table where Customer name and Year are marked as not a keyword of this document type, while the other rows show the keyword ID and whether it is required The check covers every keyword the mapping can write for that type: field rows that apply to it, values its rules set, and keyword records. For each, it shows whether the type has the keyword, in which group, and whether it is required, hidden or read-only. It also lists: * keywords the type **requires** that nothing in the mapping writes, because every upload of that type would stop on them * the same keyword written under two names The verdict matches the upload's own validation, one keyword at a time, before you spend a run on it. In the example above, Customer name and Year have rows that apply to all documents. The Claim correspondence type does not have those keywords. To fix the mapping, set **Applies to** on those rows to the document types that have them, then check again. The check uses the configuration Nobly Insight reports at that moment. After a document type or keyword change in Nobly Insight, it can take up to an hour before the check reflects it. ## Publish Workflows run a mapping's **published** version. Saving only changes the draft. To make the draft live, choose **Publish** and confirm. From then on, every workflow that names the mapping uses the new version. A run picks up the published version when it reaches its Map to Insight document step. * **Publish a mapping before the workflow that starts naming it.** A Map to Insight document step whose mapping has never been published fails every document, unless a classic mapper of the same name exists (see [Classic mappers](#classic-mappers)). * A run in the batch named `Testing` runs mapping **drafts**. That is what guided tests use, so you can test a draft end to end. Don't use `Testing` as a batch name for production submissions. * If someone else saved the mapping after you opened it, saving or publishing is refused, and the message names who changed it. Reload the page and apply your changes again. The **Versions** tab lists each published version, its date and who published it. The version workflows run is marked **runs now**. **Copy into the draft** replaces the draft with an earlier version. It publishes nothing: test the restored draft, then publish it. Versions tab listing Version 2 marked runs now and Version 1, each with the publication date, the publisher and a Copy into the draft link You can only delete a mapping that no workflow names. The refusal lists the workflows that still use it. ## Use the mapping in a workflow Add a **Map to Insight document** step before the upload step, and choose the mapping in its `MappingName` list. Below the step description, **Open the mapping** opens it in a new tab. The panel also says which version workflows run and whether the draft has unpublished changes. Step panel for the Map to Insight document step with its description, an Open the mapping Policy documents link, a note that workflows run version 2 and the draft has unpublished changes, and the MappingName list set to Policy documents The step turns the item into the document Nobly Insight receives. The item's own properties are not changed. The steps after it work with the result: | Step | Behaviour after a Map to Insight document step | | - | - | | **Upload to Nobly Insight** | Sends the mapped document. The step's own document type and document date inputs are not applied, because the mapping decides them. | | **Update keywords in Nobly Insight** | Sets every keyword the mapping lists on an existing document. A listed keyword without a value for this document is cleared. Keywords the mapping does not list are left as they are. | | **Upload JSON metadata to Nobly Insight** | Archives the item's metadata as its own document, optionally with a mapping of its own for that document's type and keywords | | A decision | Can branch on the mapped result, for example `data.Document.DocumentType == "Claim correspondence"` | When the mapping stops a document, the step fails with the explanation and the workflow takes its exception path. The run in States shows the partial result on its **Document** tab, so you can see which row stopped it. See [States and recovery](/contentflow/states-and-recovery#read-a-run). By default, the upload is strict when pass-through is off. A keyword the document type does not have fails the upload instead of being dropped. The upload step's setting for unmapped keywords can override this per workflow. ## Classic mappers Mappers created before document mappings existed are listed as **Classic mapper**. They still run where workflows use them, and nothing is converted automatically. * **Open** shows a classic mapper read as a mapping. Each keyword becomes one copy row, pass-through is on, and the document type comes from the sender. **Save as a mapping** creates a mapping with the same name. From then on, the list shows the mapping instead of the classic mapper. * A Map to Insight document step that names the classic mapper keeps running the classic mapper until the mapping of that name is **published**. * An upload step that names a classic mapper itself, without a Map to Insight document step, keeps working as before. * **Classic mapper editor** at the top of the list opens the old editor, for workflows that still depend on it. To move a workflow onto a mapping: open the classic mapper, save it as a mapping, and refine the rows. Then check it against each document type, publish it, and add a Map to Insight document step to the workflow. Test the workflow before you publish it. ## Where to read next Build the pipeline in the workflow editor: steps, decisions, the exception flow, validation and publishing. Run a sample through the draft workflow and its draft mappings, and compare the result with what you expect. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.