Documentation

# Security Configuration

Settings in the Security section of the CRM Configuration screen. They set the permissions that ContactManager puts on a new record the moment it is created: who may read it, change it and manage its permissions. See Permissions for the permission model itself.

# Table of Contents

  1. How the settings are applied
  2. Built-in defaults
  3. Entry order: the first match wins
  4. Configuration Reference
  5. Examples
  6. Points to watch

# How the settings are applied

  • The settings are applied when a contact, activity (including matters, documents and opportunities) or folder is created. They are applied again, using the record's field values at that moment, in two cases:

    • a matter is saved in the matter screen while the matter Permissions field is shown and left empty (see Matter Permissions);
    • the ReassignSecurity import is run for the record.

    Changing the settings changes existing records only through these two paths.

  • The settings are a list of entries. Each entry applies to one record type, optionally only when a field of the new record has a specific value — for example matters of one activity type (the Legal/Notary field on the matter).

  • ContactManager takes the first entry in the list that matches the new record, and uses only that entry. See Entry order.

  • If no entry matches, the new record gets no permissions of its own and inherits everything from its parent.

The settings are entered as XML. The list starts with <Security> and <Items>, and each entry is a <SecurityConfiguration> element:

<Security>
  <Items>
    <SecurityConfiguration>
      ...
    </SecurityConfiguration>
    <SecurityConfiguration>
      ...
    </SecurityConfiguration>
  </Items>
</Security>

# Built-in defaults

Out of the box the list has three entries, in this order:

Order Record type Inherits from parent Permissions set on the new record
1 Contact (persons, companies, employees, company departments) Yes Creator: Change Permissions. Administrators role: Owner.
2 Activity (also matters, documents, opportunities) Yes Creator and responsible user: Change Permissions. Administrators role: Owner.
3 IFolder (contact, search and subscription folders) Yes Administrators role: Owner.

The creator gets Change Permissions, not Change. Whether the creator can read and change the record afterwards depends on what the parent passes down. See Default permissions on a new record.

The built-in defaults as XML:

<Security>
  <Items>
    <SecurityConfiguration>
      <UseInheritedSecurity>true</UseInheritedSecurity>
      <Field />
      <FieldValue />
      <Type>Contact</Type>
      <Permissions>
        <SecurityConfigurationPermission>
          <PrincipalType>Creator</PrincipalType>
          <Name />
          <Allow>true</Allow>
          <Permission>ChangePermissionsPermission</Permission>
        </SecurityConfigurationPermission>
        <SecurityConfigurationPermission>
          <PrincipalType>Principal</PrincipalType>
          <Name>Administrators</Name>
          <Allow>true</Allow>
          <Permission>OwnerPermission</Permission>
        </SecurityConfigurationPermission>
      </Permissions>
    </SecurityConfiguration>
    <SecurityConfiguration>
      <UseInheritedSecurity>true</UseInheritedSecurity>
      <Field />
      <FieldValue />
      <Type>Activity</Type>
      <Permissions>
        <SecurityConfigurationPermission>
          <PrincipalType>Creator</PrincipalType>
          <Name />
          <Allow>true</Allow>
          <Permission>ChangePermissionsPermission</Permission>
        </SecurityConfigurationPermission>
        <SecurityConfigurationPermission>
          <PrincipalType>Owner</PrincipalType>
          <Name />
          <Allow>true</Allow>
          <Permission>ChangePermissionsPermission</Permission>
        </SecurityConfigurationPermission>
        <SecurityConfigurationPermission>
          <PrincipalType>Principal</PrincipalType>
          <Name>Administrators</Name>
          <Allow>true</Allow>
          <Permission>OwnerPermission</Permission>
        </SecurityConfigurationPermission>
      </Permissions>
    </SecurityConfiguration>
    <SecurityConfiguration>
      <UseInheritedSecurity>true</UseInheritedSecurity>
      <Field />
      <FieldValue />
      <Type>IFolder</Type>
      <Permissions>
        <SecurityConfigurationPermission>
          <PrincipalType>Principal</PrincipalType>
          <Name>Administrators</Name>
          <Allow>true</Allow>
          <Permission>OwnerPermission</Permission>
        </SecurityConfigurationPermission>
      </Permissions>
    </SecurityConfiguration>
  </Items>
</Security>

# Entry order: the first match wins

An entry matches a new record when:

  • the record is of the entry's Type, or of a type derived from it; and
  • the entry has no Field, or the record's Field has the value in FieldValue.

ContactManager checks the entries from top to bottom and stops at the first match. A more general entry therefore hides every more specific entry below it.

A matter is a kind of activity, so the Activity entry also matches every new matter. To give matters their own permissions, add an entry with Type Matter and put it above the Activity entry. If the Matter entry is below Activity, the Activity entry wins and the Matter entry is never used.

The same applies to documents and opportunities under Activity, to persons and companies under Contact, and to contact folders under IFolder. As a rule, order the entries from most specific to most general:

  1. a type with a field condition (for example Matter where the activity type is MATTER_PRIVATE);
  2. the same type without a condition (Matter);
  3. the general type (Activity).

# Configuration Reference

# Entry

Each <SecurityConfiguration> entry has these elements:

Element What it does Values Default
Type The record type the entry applies to. Also applies to types derived from it. A name from Record types — (required)
Field Optional condition: the field of the new record to check. Leave empty to apply the entry to every record of the type. Use a dot to read a field of a linked record, for example ActivityType.Code for the code of a matter's activity type (the Legal/Notary field). A field name, or empty empty
FieldValue The value the Field must have for the entry to match. The comparison is not case-sensitive. Text empty
UseInheritedSecurity Whether the new record inherits the permissions of its parent. Set to false to make the record use only the permissions of this entry. true or false true
Permissions The permissions to set on the new record: a list of <SecurityConfigurationPermission> lines. See Permission line empty

# Permission line

Each <SecurityConfigurationPermission> line gives one permission to one user, role or kind of user:

Element What it does Values
PrincipalType Who gets the permission. Creator — the user who created the record. Owner — the record's responsible user. OwnerSub — the record's second responsible user. Principal — the users or roles named in Name.
Name Only for Principal: the name of a user or role. Separate several names with a comma or semicolon. A name that does not exist is skipped. Leave empty for the other types. User or role names
Allow true gives the permission; false denies it. See Allow and Deny. true or false
Permission The permission. A name from Permission names

Owner works on activities (including matters, documents and opportunities), contacts, and contact, search and subscription folders. OwnerSub works on matters and contacts. A line is skipped when the field is empty at the moment the settings are applied; for a contact created in the screens that is usually the case, so the line takes effect when the settings are applied again.

Owner and OwnerSub use the responsible user and second responsible user the record has at the moment the settings are applied:

  • A matter created by an import or an integration gets its responsible user on creation, so Owner works. The second responsible user is filled in afterwards, so OwnerSub finds nobody.
  • In the matter screen, the settings are applied again at the end of the save when the matter Permissions field is shown and left empty (see Matter Permissions). Both lines then use the users chosen in the form.
  • In the matter screen without that field, Owner is the user who creates the matter and OwnerSub finds nobody.

# Record types

Use one of these names in Type:

Type Applies to
Contact Every contact: persons, companies, employees, company departments
Person Persons
Company Companies
Employee Employees
CompanyDepartment Company departments
Activity Every activity, including matters, documents and opportunities
Matter Matters
Document Documents
Opportunity Opportunities
IFolder Contact folders, search folders and subscription folders. Other folders do not get these settings.
ContactFolder Contact folders

# Permission names

In Permission, use the name in the right-hand column. Case does not matter.

Permission (as shown in the permission screens) Name in the Security settings
Owner OwnerPermission
Read ReadPermission
Read summary ReadSummaryInfoPermission
Change ChangePermission
Remove RemovePermission
Read Permissions ReadPermissionsPermission
Change Permissions ChangePermissionsPermission
List items EnumerateChildNodesPermission
Create new items CreateChildNodesPermission
Remove items from folder RemoveChildNodesPermission
Create new folder CreateFolderPermission
Change Folder ChangeFolderPermission
Remove Folder RemoveFolderPermission
Change Important Information ChangeCompanyNamePermission
Change Marketing Information ChangeMarketingInformationPermission
Verify VerifyPermission

# Examples

The examples below show only the entries that are added. Keep the built-in Contact, Activity and IFolder entries in the list, below the new entries.

# Example 1: Private matters for one activity type

Matters of the activity type (Legal/Notary) with code MATTER_PRIVATE must be visible only to the creator, the responsible user and the Finance role. Other matters keep the default behaviour.

The entry has Type Matter and the condition ActivityType.Code = MATTER_PRIVATE. Inheritance is switched off, so the permissions of the contact or folder the matter is created under do not apply.

<SecurityConfiguration>
  <UseInheritedSecurity>false</UseInheritedSecurity>
  <Field>ActivityType.Code</Field>
  <FieldValue>MATTER_PRIVATE</FieldValue>
  <Type>Matter</Type>
  <Permissions>
    <SecurityConfigurationPermission>
      <PrincipalType>Creator</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Owner</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Finance</Name>
      <Allow>true</Allow>
      <Permission>ReadPermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Administrators</Name>
      <Allow>true</Allow>
      <Permission>OwnerPermission</Permission>
    </SecurityConfigurationPermission>
  </Permissions>
</SecurityConfiguration>

Put this entry above the Activity entry. Always give someone Owner or Change Permissions (here: the Administrators role), so the matter never ends up without anyone who can manage its permissions.

# Example 2: Different groups per activity type

A firm has two matter activity types (Legal/Notary): litigation (code MATTER_LIT) and notarial (code MATTER_NOT). Litigation matters may be changed by the Litigation role and read by the Notarial role; notarial matters the other way around. The Staff role may read both. All other matters, and all other activities, keep the default behaviour.

The order of the list:

  1. Matter where ActivityType.Code = MATTER_LIT
  2. Matter where ActivityType.Code = MATTER_NOT
  3. Contact (built-in)
  4. Activity (built-in)
  5. IFolder (built-in)
<SecurityConfiguration>
  <UseInheritedSecurity>false</UseInheritedSecurity>
  <Field>ActivityType.Code</Field>
  <FieldValue>MATTER_LIT</FieldValue>
  <Type>Matter</Type>
  <Permissions>
    <SecurityConfigurationPermission>
      <PrincipalType>Creator</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Litigation</Name>
      <Allow>true</Allow>
      <Permission>ChangePermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Notarial; Staff</Name>
      <Allow>true</Allow>
      <Permission>ReadPermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Administrators</Name>
      <Allow>true</Allow>
      <Permission>OwnerPermission</Permission>
    </SecurityConfigurationPermission>
  </Permissions>
</SecurityConfiguration>
<SecurityConfiguration>
  <UseInheritedSecurity>false</UseInheritedSecurity>
  <Field>ActivityType.Code</Field>
  <FieldValue>MATTER_NOT</FieldValue>
  <Type>Matter</Type>
  <Permissions>
    <SecurityConfigurationPermission>
      <PrincipalType>Creator</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Notarial</Name>
      <Allow>true</Allow>
      <Permission>ChangePermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Litigation; Staff</Name>
      <Allow>true</Allow>
      <Permission>ReadPermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Administrators</Name>
      <Allow>true</Allow>
      <Permission>OwnerPermission</Permission>
    </SecurityConfigurationPermission>
  </Permissions>
</SecurityConfiguration>

# Example 3: The second responsible user on every matter

Every new matter, whatever its type, must also give Change Permissions to its second responsible user. Inheritance stays on, so the matter still gets the permissions of its contact or folder.

The entry has Type Matter and no Field, so it matches every matter. It must be above the Activity entry. When combined with examples 1 or 2, put it below their entries: an entry without a condition would otherwise hide the entries with a condition.

The OwnerSub line only takes effect when the settings are applied after the second responsible user is filled in: in the matter screen with the Permissions field shown, or through the ReassignSecurity import. See Permission line.

<SecurityConfiguration>
  <UseInheritedSecurity>true</UseInheritedSecurity>
  <Field />
  <FieldValue />
  <Type>Matter</Type>
  <Permissions>
    <SecurityConfigurationPermission>
      <PrincipalType>Creator</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermissionsPermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Owner</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermissionsPermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>OwnerSub</PrincipalType>
      <Name />
      <Allow>true</Allow>
      <Permission>ChangePermissionsPermission</Permission>
    </SecurityConfigurationPermission>
    <SecurityConfigurationPermission>
      <PrincipalType>Principal</PrincipalType>
      <Name>Administrators</Name>
      <Allow>true</Allow>
      <Permission>OwnerPermission</Permission>
    </SecurityConfigurationPermission>
  </Permissions>
</SecurityConfiguration>

An entry replaces the Activity entry for the records it matches; it does not add to it. Repeat the lines of the Activity entry you want to keep, as the creator, owner and Administrators lines above.

# Points to watch

  • Order matters. A new entry for Matter, Document, Opportunity, Person or Company has no effect when it is below the general Activity or Contact entry.
  • The condition is checked each time the settings are applied. Use a field that is known when the record is created, such as the activity type. Changing the activity type of an existing matter changes its permissions only when the settings are applied again (see How the settings are applied).
  • Use the activity type, not the Matter Type. A matter has both a Legal/Notary field (its activity type) and a Matter Type field. Only the activity type can be used as a condition: the matter screen fills in Matter Type after the matter is created, so it is still empty when the settings are applied.
  • Use the code, not the name, of the activity type. ActivityType.Code compares the code of the activity type; FieldValue must hold that code.
  • Matter activity type codes start with MATTER. The Legal/Notary field only offers activity types whose code starts with MATTER, and a matter without a choice gets MATTER itself. A FieldValue such as PRIVATE therefore never matches a matter created in the screens; use for example MATTER_PRIVATE.
  • Switching off inheritance means only the permissions in the entry apply. Include everyone who must see the record, and at least one user or role with Owner or Change Permissions.
  • Existing records keep their permissions until the settings are applied again. To apply changed settings to existing records, run the ReassignSecurity import. For a single matter, save it with an empty Permissions field (see Matter Permissions).
Last Updated: 10/8/2026, 10:59:28 AM

← Synchronization Configuration →