Skip to content

Content Types and Profiles

Use a content type to attach a profile form and its data model to a document. The profile records structured business information about the document; it does not replace its files, standard metadata, or access rules.

This page uses the Sample contract introduced in Document Management. The example names below must be created in your test domain before you use them.

Decide What Belongs in the Profile

Keep the contract title in the document's standard Title field and the contract text in an attached file. Put the contract number and effective date in the Contract profile so users can enter and review them as structured fields.

Item Example definition
Form template name ContractProfile
Template data root Contract
Content type Name Contract
Content type Caption Contract
Profile field Number String; example EXAMPLE-001.
Profile field EffectiveDate Date; example 2026-01-01.

The template name identifies the reusable form design. The content type name is the association selected on a document or passed to $Documents.New. The data root defines the profile XML shape. Using the same name for the content type and data root here is a convention for this example, not a requirement that all three names match.

Design the Profile Form

Prerequisites: access to edit and publish the source process definition, familiarity with Form Templates, and a test domain in which the name Contract is available. Content types are published into the domain; coordinate names with other process designers.

  1. Create a form template named ContractProfile in the source process definition.
  2. Define its data root as Contract and include Number as a string and EffectiveDate as a date in its data model. Follow the form-template data-model conventions; a reusable template can use a named schema type.
  3. Add a text control bound to Number and a date control bound to EffectiveDate. These paths are relative to the template's data root, so do not repeat Contract/ inside the template controls.
  4. Add the labels and validation rules needed by the business. Check form validation in the intended document screen; do not assume browser form rules validate every server-side import.
  5. Preview the form and check that both values can be entered and displayed.

The profile form collects information about a contract. It does not upload or generate the contract file by itself.

Publish the Content Type

  1. In the source process definition's Content Types, use Add New Content Type.
  2. Set Name to Contract and Caption to Contract.
  3. Select ContractProfile in Template. Confirm that the selected template has the intended data root and fields.
  4. Validate and publish the source process definition so its content type is provisioned in the domain.
  5. Open a new document in that domain and check that Content Type offers Contract and displays the two profile fields when selected. This check does not require saving a document.

The published content type packages the selected form template with its required schema. Keep its source definition as the place to maintain the design. A conflicting name owned by another source process is rejected during publication; do not rename a type merely to bypass a conflict without checking its existing consumers.

Associate the Profile with a Document

From the document screen, select Contract in Content Type and enter the contract number and effective date under Profile. The document form hosts the selected content type; the user does not need to add a separate profile widget. See Register a Contract.

In a server-side script, set the published content type on the draft before calling AddProfile:

1
2
3
4
5
var document = $Documents.New('Sample contract');
document.ContentType = 'Contract';
document.AddProfile(
    '<Contract><Number>EXAMPLE-001</Number><EffectiveDate>2026-01-01</EffectiveDate></Contract>'
);

The ContentType assignment attaches the profile form and schema used by the subsequent AddProfile call. The type must already exist in the current domain. Assign it while the document is Draft; a published version's content type is read-only through the script API.

AddProfile copies the supplied data according to the content type's schema. This example uses an empty XML namespace; if your template uses a namespace, use that namespace in the data and configure XPath namespaces when reading or writing it. Match field names, case, and data types; arbitrary XML is not a replacement for the content type association.

The snippet above prepares a draft only. Follow Create and Publish Documents to attach files, set the reviewed security profile, and publish it into Documentation → Contracts.

Read and Update the Profile

For a document associated with the example content type, the Profile property exposes an XML wrapper around the Contract data. In the example's namespace-free schema, paths are relative to that wrapper:

1
2
3
var number = document.Profile.Evaluate('Contract/Number');
document.Profile.SetValue('Contract/EffectiveDate', '2026-02-01');
document.Save();

This updates profile data on the same version. It does not replace an attachment or create a new revision. When a change to the contract file must preserve the previous contents, create a new document version; that draft starts with copies of the existing profile and files. See lifecycle and file behavior.

A document without a content type has no associated profile form. Treat profile access as dependent on the expected content type and data being present; generic scripts must check the association and handle missing profile data before using fields such as Contract/Number.

Keep Profile Design and Access Separate

Contract defines the business fields. The administrator's Contract Access security profile defines document access. Selecting a content type does not grant readers permission to open its documents. Review the collection's access setup and script authorization before exposing document automation to users.

Change an Existing Profile Design

Maintain the form template and schema in the source definition, then publish the updated definition through the normal process-version workflow. The content type is shared by its consumers, so review existing documents as well as new ones.

Before changing field names, namespaces, types, or required fields, test representative existing profile data and scripts that use those paths. Do not assume that republishing a form migrates stored profile values, rewrites attachments, or creates new document versions. Plan any required data migration separately and preserve the previous source definition for recovery.

Troubleshooting

Symptom Check Verify the correction
Contract is missing from Content Type Confirm the domain, published source definition, Name, and Template association. Reopen a new document and select Contract.
Type is listed but expected fields are absent Check the selected template, its data root, and the published form contents. Reopen the form and confirm both field labels.
Imported values are empty or incorrect Compare the input root, namespaces, field case, and schema types. Inspect the stored profile and reopen its form.
Content type change fails in a script Check whether the version is already Published, Archived, or Deleted. Set the intended type on a Draft and verify its profile before publishing.
A reader cannot open the contract Review document ACL separately from the content type. Test with the intended allowed and denied readers.