Create and Publish Documents¶
Run these small examples as authorized server-side scripts in a test domain. Agree the destination folders and document security profile with an administrator. Each example performs writes; rerunning it creates another record or revision. See failure and retry handling before using it in a retryable workflow.
Publish a New Document¶
Prerequisite: a domain security profile named Contract Access whose effective rules grant the intended readers access. Create the Contract content type with the Number and EffectiveDate fields as described in Content Types and Profiles. The folder is Documentation → Contracts; all names are example configuration, not built-in objects.
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Record both IDs in your application's durable result. Confirm the folder lists version 1.0.0, both files download, and the profile shows EXAMPLE-001 and 2026-01-01. Check that an intended reader can open it while a denied account cannot. Save() would persist a draft without publishing it there.
Publish a New Version¶
Prerequisites: an existing document version ID in process field DocumentId, plus application authorization to revise that family. Use the Sample contract created above. This example deliberately retains its copied profile and files, updates the new revision's effective date, and adds a revision note.
1 2 3 4 5 6 7 8 9 | |
Define ResultVersionId in the process model before using this snippet. Publish() preserves existing family folder associations and adds none; if the family has no folder association, supply a reviewed path explicitly. A copied file that is being superseded must be removed from the new draft with revision.Files.Delete(copiedFileId) before adding its replacement. Use an ID from the new revision, not from current.Files.
Confirm the new version appears in the folder, History opens both published revisions, and the original files and effective date are unchanged. The result field shown here records the outcome; it is not an atomic retry guard by itself.
Publish a Document with a Profile¶
Prerequisites: a published content type named Contract with data root Contract, string Number, and date EffectiveDate fields, plus the reviewed Contract Access security profile. Publish the content type from a form template before running the example.
Set ContentType before calling AddProfile so the profile uses the selected type's form and schema. Run this example on a separate fixture rather than creating the same business contract twice.
1 2 3 4 5 6 7 8 9 | |
The Contract content type attaches the profile form and defines Number and EffectiveDate; AddProfile supplies its data. Adapt the XML to the actual content type's schema, including namespaces. Reopen the document and verify the profile form shows EXAMPLE-001 and 2026-01-01. Then update the profile of the published version:
1 2 | |
Confirm the profile value changed while Id, Version, state, and file contents stayed the same. This illustrates why a profile edit and a content revision are different operations.