Skip to main content

Super Admin Tools

Who Can Access This​

The Super Admin section (/admin/super) is only accessible to users with the Super Admin flag on their account. Regular project administrators will see an error if they try to open it.

If you need one of these operations performed and do not have super admin access, contact your system administrator.

warning

These are platform-wide maintenance tools. Most of them affect the entire system, not just one project. Use them carefully and only when needed.

Rebuilding System Definitions​

The platform stores internal rules about how records are structured, what fields can be searched, and what values are valid. When the ChartChat server is updated, these rules may need to be refreshed to match the new version.

There are three buttons for this, and they should be run in order when doing a full refresh after a server update.

warning

Always run them in this order and wait for each one to finish before starting the next:

  1. Rebuild StructureDefinitions
  2. Rebuild SearchParameters
  3. Rebuild ValueSets

All three run in the background — after clicking you will see a notification that the job has started. Check the Background Job Monitor to see when it completes.

Rebuild StructureDefinitions​

What it does: Refreshes the platform's internal record of what fields each record type has — things like what information a Patient record can hold, what a Lab Result looks like, and what custom record types ChartChat has added.

When to use it:

  • After a ChartChat server update
  • If a record page in the Data Browser is showing missing or incorrect fields
  • If you get an error saying a record type does not exist when it should

How to run:

  1. Go to Super Admin (/admin/super)
  2. Find the Structure Definitions section
  3. Click Rebuild StructureDefinitions
  4. Check the Background Job Monitor and wait for it to show Completed

Rebuild SearchParameters​

What it does: Refreshes the rules that make search filters work. Without this, search filters across the platform may stop returning correct results after an update.

When to use it:

  • After a ChartChat server update
  • After running Rebuild StructureDefinitions — always do this immediately after
  • When a search filter is returning no results when it should

How to run:

  1. Go to Super Admin (/admin/super)
  2. Find the Search Parameters section
  3. Click Rebuild SearchParameters
  4. Check the Background Job Monitor and wait for Completed

Rebuild ValueSets​

What it does: Refreshes the lists of valid options used throughout the platform — for example, the dropdown choices in record edit forms. If dropdowns are showing wrong or missing options, this fixes it.

When to use it:

  • After a ChartChat server update
  • After running Rebuild SearchParameters — always the last step
  • When a dropdown in the Data Browser shows wrong or missing options

How to run:

  1. Go to Super Admin (/admin/super)
  2. Find the Value Sets section
  3. Click Rebuild ValueSets
  4. Check the Background Job Monitor and wait for Completed

Reindex Resources​

What it does: Rebuilds the internal search index for a specific record type. The platform keeps a separate lookup table for each record type to make searches fast. If that lookup table gets out of sync — for example after a server update — searches may return missing or incorrect results even though the data is there. Reindexing rebuilds it.

When to use it:

  • After a server update, if searches for a specific record type are returning wrong results
  • After rebuilding Search Parameters — existing records need to be reindexed so the new search rules apply to them
  • When search results look incomplete or incorrect and other troubleshooting has not helped

The form:

FieldWhat to enter
Resource TypeThe type of record to reindex, e.g. Patient, Observation. One type per run.
Search FilterOptional — limit to a subset of records. Leave blank to reindex all records of that type.
Max Resource VersionLeave as Outdated resources for normal use. This is the fastest option and skips records that are already up to date.

How to run:

  1. Go to Super Admin (/admin/super)
  2. Find Reindex Resources
  3. Enter the record type (e.g. Observation)
  4. Leave the other fields at their defaults unless you have a specific reason to change them
  5. Click Reindex
  6. Check the Background Job Monitor for progress
warning

Reindexing a large record type like Observation or AuditEvent can take a long time on a busy system. Run it during off-peak hours. It runs in the background and will not interrupt normal portal use, but it does add load to the database.

Purge Old Records​

What it does: Permanently deletes old system-generated records that accumulate over time and are no longer needed. The two types that can be purged are:

TypeWhat it is
AuditEventA log entry created every time anyone logs in, views data, or makes a change. These pile up quickly on an active system.
LoginA session record created each time a user signs in. Old sessions have no value after they expire.

When to use it:

  • When database storage is growing faster than expected
  • As part of routine maintenance (e.g., purge records older than 90 days each quarter)
  • Before a large database backup to reduce its size

Important — check your retention policy first: Some organisations are required by law to keep audit logs for a minimum number of years (e.g., 6 years under HIPAA). Do not purge records that fall within your required retention window. If you are unsure, check with your compliance team before running this.

How to run:

  1. Go to Super Admin (/admin/super)
  2. Find Purge Resources
  3. Select the record type — AuditEvent or Login
  4. Set the Purge Before date — all records older than this date will be deleted
  5. Click Purge
  6. You will see a green confirmation when done
danger

Purge is permanent. There is no undo. Records deleted this way are gone from the database completely. Always double-check the date and record type before clicking Purge.

Force Set Password​

There are two versions of this tool depending on your access level.

Super Admin version (/admin/super)​

Sets a new password for any user account by email address. Use this when the normal password reset email is not working — for example, if email delivery is broken or the user is completely locked out.

By default this resets the password across all projects. If you enter a Project ID, the reset is scoped to that project only (safer).

When to use:

  • A user is locked out and the "Forgot Password" email is not arriving
  • Emergency access recovery for an admin account

How to find the Project ID (if you want to scope it):

  1. In the Admin Portal, go to /Project in the Data Browser
  2. Click the project — the ID appears in the URL (a long code like a1b2c3d4-e5f6-...)
  3. Copy and paste it into the Project ID field

How to use:

  1. Go to Super Admin (/admin/super)
  2. Find Force Set Password
  3. Enter the user's email, a new temporary password, and optionally the Project ID
  4. Click Force Set Password
  5. Tell the user their temporary password and ask them to change it immediately after signing in
warning

The user's old password stops working immediately when you click the button. Make sure you have the right email address before proceeding.

Project Admin version (/admin/config)​

This simpler version is available to any project administrator — no super admin access needed. It resets the password for the current project only.

When to use:

  • A staff member cannot log in and the "Forgot Password" email is not working
  • You created an account manually and need to set an initial password for them

How to use:

  1. Navigate to /admin/config
  2. Find Force Set Password
  3. Enter the user's email and a new temporary password
  4. Click Force Set Password
  5. Tell the user their password and ask them to change it after signing in

Use this version first. Only use the Super Admin version if this does not work or you need to reset across all projects.

Database Stats​

What it does: Shows how large each database table is — how many records it contains and how much storage it is using.

When to use it:

  • To check how many records exist before running a purge or reindex
  • If database storage is growing unexpectedly and you want to find the largest tables
  • After a purge, to confirm the record count went down

How to use:

  1. Go to Super Admin (/admin/super)
  2. Find Database Stats
  3. Optionally enter specific table names (e.g. AuditEvent,Login,Patient) — leave blank for all tables
  4. Click Get Database Stats
  5. A panel shows row counts and size estimates for each table

Database Invalid Indexes​

What it does: Checks whether any internal database indexes are broken. A broken index means searches that rely on it may return incomplete results or run very slowly without any obvious error.

When to use it:

  • After an unexpected server crash or restart
  • When search results seem incomplete and you cannot explain why
  • As a routine check after a server upgrade

How to use:

  1. Go to Super Admin (/admin/super)
  2. Find Database Invalid Indexes
  3. Click Get Database Invalid Indexes

What the result means:

  • Nothing listed — all indexes are healthy. No action needed.
  • One or more indexes listed — those indexes are broken and need to be repaired. Share the list with the development team — this cannot be fixed from the Admin Portal and requires direct database access.

Database Schema Drift​

What it does: Checks whether the database structure matches what the current server version expects. After a server update that includes database changes, this shows what needs to be updated and lets you apply those changes.

The two buttons:

ButtonWhat it does
Get Schema DriftShows what changes are needed — does not change anything. Use this to review first.
Reconcile Schema DriftActually applies those changes to the live database. This cannot be undone.

When to use it:

  • Right after deploying a new version of the ChartChat server
  • When a new feature is not working and the server update may not have fully applied

How to use safely:

  1. Click Get Schema Drift first and review what it shows
  2. If it looks correct, take a database backup
  3. Click Reconcile Schema Drift to apply the changes
  4. Check the Background Job Monitor for completion
danger

Reconcile Schema Drift makes permanent changes to the live database. If anything looks unexpected in the preview, stop and contact the development team before proceeding. Always take a database backup first on a production system.

Reload Cron (Scheduled Bots)​

What it does: Restarts the scheduler for all automated bots that run on a timer (e.g., a bot that checks for stale records every night at midnight). If a scheduled bot has stopped firing at the expected times, this resets the schedule and gets it running again.

When to use it:

  • A scheduled bot has stopped running at its expected times
  • A bot's schedule was recently changed but the new schedule is not being picked up
  • After a server restart where the scheduler may have been lost

How to use:

  1. Go to Super Admin (/admin/super)
  2. Find Reload Cron Resources
  3. Click Reload Cron Resources
  4. Check the Background Job Monitor and wait for Completed

This is safe to run at any time. It does not delete bots or data — it only resets the scheduling queue.

Background Job Monitor​

Route: /admin/super/asyncjob

Several tools on this page run in the background rather than finishing instantly — Rebuild, Reindex, Reconcile Schema Drift, and Reload Cron all work this way. After you click one of those buttons, come here to see if the job finished successfully.

What the statuses mean:

StatusMeaning
AcceptedJob is waiting in the queue
ActiveJob is currently running
CompletedJob finished successfully
ErrorJob failed — click the row to see the error message

If a job fails:

  • For Rebuild jobs — safe to try again by clicking the button again
  • For Reconcile Schema Drift — do not retry without understanding why it failed. Contact the development team with the error message.
  • For Reindex — check the resource type name was entered correctly and try again

Remove Bot Jobs from Queue​

What it does: Clears all waiting jobs for a specific bot. Use this when a bot is misbehaving — for example, if a bug is causing it to fail repeatedly and flood the queue with thousands of retries — without deleting the bot itself.

This only removes jobs that have not started yet. It does not affect jobs that are currently running and does not prevent the bot from running again for new events after the queue is cleared.

How to find the Bot ID:

  1. Go to Admin → Bots (/admin/bots)
  2. Click the bot you want to stop
  3. The ID appears in the page URL — copy the long code after the last /

How to use:

  1. Go to Super Admin (/admin/super)
  2. Find Remove Bot ID Jobs from Queue
  3. Paste the Bot ID
  4. Click Remove Jobs by Bot ID
  5. You will see a green confirmation when the queue is cleared

After clearing the queue, fix the bot's code, redeploy it, and check the Audit Log to confirm it is running correctly.

Database Tools (/admin/super/db)​

This is a separate page for advanced database performance settings. Navigate to it via /admin/super/db.

warning

These settings affect database performance at a low level. Only change them if you know what you are doing or have been instructed to by the development team.

GIN Index Settings​

GIN indexes help the database answer search queries faster. This page lets you adjust two performance settings for those indexes across specific tables.

Configure GIN Indexes — change settings on one or more tables:

  1. Select the table(s) you want to adjust
  2. Change fastupdate or gin_pending_list_limit as instructed by the development team
  3. Click Update and check the Background Job Monitor for completion

GIN Index Stats — view the current settings for any table:

  1. Select a table from the dropdown
  2. Click Refresh to see the current index configuration

If you are unsure whether to change these settings, ask the development team first.