Skip to main content
Version: 3.2

Cherwell System Functions Not Populating for the Current User

Symptoms​

One or more of these happens for a signed-in user of a Cherwell archive:

  • The user can open the archive but sees no records at all — searches, browse and saved searches all come back empty, while other users see the same data normally.
  • A field, label or filter that uses a system function about the current user (for example CurrentUserRecordID, CurrentUserDisplayName, CurrentUserEmail, CurrentUserDepartmentName, CurrentUserDefaultTeamName or CurrentUserDefaultTeamID) shows <<unmapped>> or a blank value.

Cause​

For each signed-in account, Cortex resolves a Cherwell user (a UserInfo record) in the archive it is reading. Two things depend on that resolution:

  1. System functions that describe the current user. These are evaluated from the mapped Cherwell UserInfo record — for example CurrentUserDepartmentName is read from that record's department field.
  2. Cherwell security group visibility filters. A Cherwell security group can carry a filter on a business object that is appended to every query executed by members of that group. Those filters commonly reference current-user system functions, such as keeping only the records whose department matches CurrentUserDepartmentName.

When Cortex cannot resolve the signed-in account to a Cherwell UserInfo record, the current-user system functions have no value to return. Instead of a real value they return the placeholder <<unmapped>>, which is deliberately used so a comparison never accidentally matches blank or null database values. A visibility filter that references such a function is then comparing the stored field against the literal text <<unmapped>>, which matches nothing — the user gets an empty result set and appears to have no access.

The same empty-result outcome happens when the account has no Cherwell security group at all: without a group the user is not granted access to any business object, so every query is filtered out.

Situations that leave an account without a matching Cherwell user record:

  • A new employee who has a Cortex account but no Cherwell UserInfo record yet.
  • Someone whose Cherwell account has been removed, disabled, or renamed since the archive was taken.
  • An identifier mismatch — the username or email address Cortex looks up does not match what the archive stores for that person.

Step 1 — See what the system functions evaluate to​

Cortex can show you the value every supported Cherwell system function resolves to for the account that is currently signed in.

  1. Go to the archive's Structure → Database Inspector.
  2. Open the Troubleshooting tab, then the System Functions tab.
  3. Each supported function is listed with the value it evaluates to right now.

If the current-user functions show <<unmapped>>, Cortex could not resolve the signed-in account to a Cherwell user record — continue to Step 2.

note

The values shown are for the account signed in to Cortex, so run this from the affected account (or from a test account that is set up the same way) to reproduce what that user sees.

See Database Inspector & Diagnostics for the other diagnostic tools on this tab.

Step 2 — Check whether the user is mapped to a Cherwell user​

  1. Click your user name in the navigation footer (bottom of the navigation menu) to open the Current User Profile page.
  2. Under Cherwell, each archive is listed with the User RecID Cortex resolved for that user, and the user's full name from the archive.
  3. If it reads "No Cherwell user record mapped for this archive", that archive has no mapping for this account — this is the condition that produces <<unmapped>>.

Cortex attempts to resolve this mapping automatically from the archive's own user data the first time an account uses that archive, and stores the result per archive. A mapping that is missing, or that points at a record which no longer exists in the archive, leaves the user without a Cherwell user record.

Administrators can also set or correct the mapping — see Resolution below.

Step 3 — Find the security group filter that is hiding the records​

If the user is mapped but still sees nothing, inspect the filters on the Cherwell security group the user belongs to:

  1. Go to the archive's Structure → Security Groups.
  2. Select the security group the user belongs to in Cherwell.
  3. Open the Bus Ob Rights tab and tick Show only businessobjects that have query visibility filters, then select the business object whose records are missing.
  4. The VisibilityFilters tab shows the filter clause. This is the criteria that will be appended to every query executed by members of this security group.

If that clause references a current-user system function that returned <<unmapped>> in Step 1 — or a user field that is empty in the archive — that is why the user sees no records.

Resolution​

Option 1 — Map the user to an existing Cherwell user​

Point the Cortex account at a Cherwell UserInfo record whose values satisfy the security group's filters (the correct department, team, and so on):

  1. Go to Admin → User Management.
  2. Find the user and click the assignment icon in the Actions column to open Edit Group Assignments.
  3. On the card for the affected Cherwell archive, use the Cherwell user field to enter the UserInfo RecID, or click Search for user to look the record up by name.
  4. Click Save.

The same mapping can be set directly from the Cherwell User RecID column on the User Management grid, using its Search Cherwell user… button.

This is the right choice when the person still exists in Cherwell data, or when you want them to see records based on another Cherwell user's values.

Option 2 — Map the user to a security group without the filter​

If the person should not be treated as an existing Cherwell user, assign them a Cherwell security group that does not carry the restrictive visibility filters:

  1. Go to Admin → User Management and open Edit Group Assignments for the user.
  2. On the card for the affected Cherwell archive, use the Security group dropdown — Override the security group used for this archive — to select the filter-free group.
  3. Click Save.

Custom security group assignments are stored per user and per data source, so this only changes what that user sees in that archive.

tip

A user must have a Cherwell security group assigned before they can access any data. See Adding Users for the user and group model, and Security Groups for how Cortex authorizes against Cherwell security groups.

Option 3 — Work with Synapse Software Support​

If neither of the above is acceptable — for example the user genuinely needs the field values of a Cherwell record that no longer exists, or every suitable Cherwell security group carries the filter — contact your Synapse Software support channel.

A possible avenue is the Def Overrides utility, found in the archive's Structure → Database Inspector → Def Overrides tab. A def override substitutes an archive definition with custom details. Applied to an unused Cherwell security group, this lets support give that group a different filter set, and the user can then be mapped to it with Option 2.

warning

Def overrides replace archive definitions wholesale and are intended to be used only under the guidance of Synapse Software support. An incorrect override can cause unexpected behaviour across the whole archive.

Data source defaults for users who never existed in Cherwell​

The Cherwell data source settings include a System functions group intended for exactly this situation — "Default values for system functions for Cortex users who never existed in this Cherwell system."

The only function with a configurable default today is CurrentRoleName:

  1. Open Admin → Data Sources and edit the Cherwell data source.
  2. Open the Cherwell tab, then select Forms & expressions in the list on the left.
  3. Under System functions, set Default for CurrentRoleName when the security group has no role.
  4. Click Save.

This value is only used when evaluating the CurrentRoleName function. It does not decide which Cherwell security group an unmatched user is assigned, so on its own it does not make a user visible to a visibility filter that references another system function.

Important notes​

  • Do not edit user rows in the Cortex database directly to change data access. The Cherwell security group column there is a mapping that controls access to source data, and changing it will break that user's access — see Post-Upgrade Security Group Permissions.
  • CurrentRoleName behaves differently from the other current-user functions: it is resolved from the user's Cherwell security group (falling back to the data source default described above) rather than from their Cherwell user record, so it does not return <<unmapped>>.
  • System functions that are not about the current user (for example CurrentDateTime or ServerDateTime) are unaffected by a missing Cherwell user mapping.
  • If a system function returns a blank value rather than <<unmapped>>, the user is mapped, but the mapped Cherwell UserInfo record's field for that function is empty.