Operations & Maintenance

• Backups & Updates
• Routine Maintenance & Monitoring
• Change Log

Backups & Updates

Backups

The CRM's data must be backed up regularly so it can be restored after a mistake or a failure.

Know your backup status. Confirm with whoever maintains the servers what is backed up, how often, where it's kept, and — crucially — that a restore has actually been tested. A backup you've never restored is a hope, not a backup.

• Before any risky operation (bulk delete, large import, configuration change), a quick export of the affected records is a personal safety net — see Chapter 4 — Managing Data.

Software updates

• EspoCRM and its extensions receive updates. They are applied Sandbox first, verified, then Production — using CBM's deployment tooling, never hand-edited on the server.
• Don't chase the newest release the day it ships; let it settle and update deliberately.

Updates are a technical operation. As the staff admin you generally request and coordinate an update rather than perform it. The mechanics live in the deployment runbooks (the CRM Builder tool and the CBM repository). See Getting Help and Next Steps.

Security certificates (HTTPS)

• The https:// certificates for the CRM and the docs site renew automatically — nothing to do. The only exception: if a browser warns about an expired or invalid certificate, flag it (see Troubleshooting & Recovery).

Where the technical details live

• Server / deploy / upgrade / recovery procedures → the CRM Builder tool and the CBM repository runbooks.
• Documentation-site specifics → infrastructure/CBM-Documentation-Site.md in the CBM repository.

Routine Maintenance & Monitoring

A simple routine

A short, regular check keeps surprises away.

Weekly-ish

• Confirm email is sending (a password reset or notification arrives).
• Confirm Google / calendar sync is current, if CBM relies on it.
• Glance at new users and access, and deactivate anyone who has left.

Monthly-ish

• Skim for duplicate or junk records and tidy up — see Duplicates, Mass Updates & Cleanup.
• Confirm backups are running and recent — see Backups & Updates.
• Note any pending updates to schedule.

Signs something needs attention

• Users report can't log in, missing records, or email not sending.
• A certificate warning on the CRM or docs site.
• The CRM is slow or unreachable.

For any of these, go to Troubleshooting & Recovery.

Background jobs

EspoCRM runs scheduled background jobs (notifications, email checks, cleanup) automatically. Administration → Scheduled Jobs lists them. If time-based things — reminders, scheduled emails — stop happening, that's a sign the background runner needs attention; flag it.

Change Log

A record of notable maintenance and configuration changes made to the CBM production CRM. The test/dev instance (crm-test.clevelandbusinessmentors.org) is the source of truth for configuration; production is kept in sync with it.

2026-06-24 — Production brought into parity with test/dev

A review found several differences between the production CRM and the canonical test configuration. Production was reconciled to match. User-visible results:

• Create/edit forms are complete. The Contact and Mentor Profile forms were missing fields; all fields now appear and accept input.
• Field and relationship names corrected. A few custom fields and links had slightly wrong internal names (a missing or duplicated leading letter); these were corrected so data and relationships line up with test.
• One-to-one relationships restored. Several links that should connect to a single record (e.g. a Mentor Profile to one Contact, an Account to one Primary Contact) had become "to-many"; they were restored to single-record links.
• Mirror fields restored. Read-only fields that display a value from a linked record (e.g. a mentor's Contact City / Phone / Personal Email) were recreated.

All custom entities now match test for fields, relationships, and forms. The CRM Builder tool that deploys configuration was also corrected, so future updates carry these names and relationships faithfully and won't reintroduce the differences.

Configuration changes are made on test first, then applied to production — never directly on production except for one-off corrections like this one.