CRM requirements checklist for self-hosted CRM

How to use this CRM requirements checklist before you shortlist platforms

Settle your CRM requirements in writing before you choose between SuiteCRM, EspoCRM and Twenty. A self-hosted CRM is a long-lived system that holds sales history, contact data and business communications, so the requirements decide what you can run, how you will secure it and what you will have to rebuild later. Write each requirement as a testable statement, then verify it against every candidate with a proof of concept that uses your own pipeline, fields and sample records. Vendor feature lists describe what a product can do, not what your configuration will need. The checklist that follows is organized by function, security, integration, operations and compliance. Functional items cover pipelines and stages, entities and custom fields, email and calendar sync, marketing and support handoffs, and reporting. Security items cover role and record-level access, login methods and audit logging. Integration items cover ERP, telephony and data import and deduplication. Operations and compliance items cover hosting, backups, upgrades, retention and privacy rights. Rank every item as a must-have or a nice-to-have before you open any vendor demo. A must-have is a requirement that would block go-live or create a compliance gap if missing. A nice-to-have is one that your team could work around for a period. Keep the list short enough that the must-haves fit on one page.

Your existing team's skills often narrow the shortlist faster than any feature comparison. SuiteCRM and EspoCRM are PHP applications on MySQL or MariaDB, while Twenty is a TypeScript application on PostgreSQL and Redis. If your operations staff already run PHP stacks and relational databases, that experience shapes patch cadence, backup routines and troubleshooting. If your engineers work in TypeScript and PostgreSQL, Twenty may fit more naturally, though it still needs a worker, a cache and a database to operate. Ask who will patch, back up and restore the system after go-live, and give that answer more weight than a single feature. An implementation partner can help you test these assumptions, but the decision about who owns the platform stays with you.

Functional CRM requirements and how to verify them

This table lists the functional CRM requirements that business and finance teams usually need to settle, why each matters, and a check to run in a sandbox or staging instance before committing to a platform. Use it as a test script: each verification step should be run with your own data and roles, not vendor demo content.

Requirement	Why it matters for business and finance teams	Verification step in sandbox or staging
Pipelines and stages	Forecasting, quota reporting and deal reviews depend on stage definitions that match how the team actually sells, including approval gates for discounts or credit terms.	Rebuild one live pipeline from current stage names and exit criteria, then move 20 sample opportunities through every stage and confirm forecast totals match a spreadsheet.
Entities and custom fields	Finance needs fields such as billing entity, tax ID, contract value and renewal date, and these must be typed and validated so reports and exports stay reliable.	Create the custom fields in staging, enter edge-case values (multi-currency amounts, blank tax IDs, long names), and confirm they appear correctly in list views, exports and API responses.
Email and calendar sync	Client communications are often business records that may need retention, so sync must capture the right mailboxes and show which messages are linked to which account.	Connect two test mailboxes, send and receive messages with a test contact, and confirm each message links to the correct record and that a deleted sync rule does not remove history.
Marketing and support handoffs	Lead status, consent flags and support escalations must pass between teams without duplicate outreach or lost context.	Run a test lead from a campaign form through qualification to a sales owner, open a support case linked to the same account, and confirm consent and ownership fields update as designed.
Data import and deduplication	Duplicate accounts distort revenue reporting and can create conflicting billing or KYC records, so import rules need a test before the full load.	Run a trial import of a sample file with known duplicates, review the match results, and record how many records were created, updated or skipped before approving the full load.
Reporting and dashboards	Finance and leadership use CRM reports for pipeline, win rates and receivable-linked deals, so each report needs a defined source and owner.	Build three reports (pipeline by stage, won value by quarter, owner activity) and reconcile totals against an independent extract from the source system for the same date range.
Roles and record-level access	Advisers, lenders or branch staff should see only the records they are entitled to, and managers need visibility without blanket access.	Create two test users in different teams, log in as each, and confirm they can see, edit and export only their own records, with an audit entry for each attempt.
Retention and privacy rights	Records of client communications and personal data may have fixed retention periods and must be locatable for access or erasure requests.	Define retention rules for a test record class, run a test access request and a test erasure request in staging, and confirm the outcome is logged and linked records are handled as agreed.

Security requirements a self-hosted CRM must meet

A self-hosted CRM holds customer contact, pipeline and communication data, so its login, API, logging and encryption choices need to be settled before configuration starts. The cards below cover the controls most buyers ask about and the checks to run against each platform. Where the reader is a covered financial institution, several of these items map directly to the FTC Safeguards Rule.

SuiteCRM 8 login through LDAP or SAML

SuiteCRM 8 supports LDAP, enabled with AUTH_TYPE=ldap, and SAML, enabled with AUTH_TYPE=saml. Choose one based on the directory your staff already use, then confirm how user accounts are created, disabled and mapped to roles when someone leaves. Test the SAML logout path before go-live, because the 8.7.0+ implementation does not support IdP-initiated logout or POST binding to the logout service.

EspoCRM OpenID Connect and LDAP

EspoCRM supports OpenID Connect sign-in, with optional user creation on first login and mapping of identity provider groups to EspoCRM teams. It also documents LDAP, including Active Directory and OpenLDAP. Confirm that a fallback login method exists for administrators, and note that EspoCRM's own two-factor authentication is not compatible with OIDC, so MFA must be enforced at the identity provider.

Twenty SSO depends on the plan tier

Twenty's self-hosted open source core can be run for free, but SAML or OIDC single sign-on and row-level permissions are listed on its Organization tier, while SCIM provisioning appears on Enterprise. Before choosing a tier, confirm which SSO and provisioning features your build actually needs and whether a commercial license applies to any Enterprise-marked files you would deploy.

API authentication for integrations

Telephony, ERP and marketing integrations often use the CRM API more than people do. EspoCRM supports API key, HMAC and basic authentication through dedicated API users with role-based permissions, and its docs describe HMAC as the most secure method and basic authentication as not recommended. Create one API user per integration, scope its role narrowly and rotate its credentials on a schedule you document.

Multi-factor authentication for every user

The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to implement multi-factor authentication for any individual accessing any information system. For a CRM, that means every staff login, including administrators, and a decision on whether API users are exempt. Confirm where MFA is enforced in each platform, since the answer differs between an identity provider and the application's own login.

Activity logging for authorized users

The Safeguards Rule also requires covered institutions to log the activity of authorized users. Define which events matter, such as record exports, permission changes, bulk deletions and logins, and confirm each platform captures them. Twenty lists audit logs on its Organization tier. For the others, verify what the application records, where logs are stored, who can edit them and how long they are kept.

Encryption in transit and at rest

The Safeguards Rule requires encryption of customer information in transit over external networks and at rest. In practice, this means TLS on every public endpoint, including the API and webhook receivers, and encrypted storage for the database, backups, attachments and any exported files. Ask the partner to document where keys are held, how they rotate and whether database backups are encrypted with the same controls as production.

Which compliance records the CRM must keep and how to prove it

Settle early whether the CRM will hold records that a retention rule covers. For broker-dealers, SEC Rule 17a-4(b) requires preservation of certain business records for not less than three years, the first two in an easily accessible place. Those records include bills receivable or payable, bank statements and originals of business communications, so client emails, call notes and attachments logged against accounts or contacts may fall inside that scope depending on how the firm uses the CRM. Ask your counsel and compliance lead which record types, retention periods and storage locations apply, and whether the CRM is the system of record or only a copy of a mail archive.

Once the obligations are known, write down how the CRM meets them. The requirements checklist should name the settings that control retention and deletion, such as which entities and fields are kept, who can delete records, whether deletions are soft or permanent, and how exports are produced for examiners. Document the export and deletion workflows step by step, test them on a staging instance, and keep dated records of each test and each configuration change. Confirm with your implementation partner how SuiteCRM, EspoCRM or Twenty handle audit logging, backup restores and deleted-record recovery in your chosen version, because these behaviors differ and should not be assumed.

DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and that work belongs to independent auditors or certification bodies. In practice, the partner can configure the CRM, set up access and logging, document the procedures and assemble the evidence an assessor will ask for. Agree in writing which controls are in scope, who owns each procedure after handover and which evidence the client must retain. Your assessor will decide whether that evidence is sufficient.

Integration requirements with ERP, telephony and marketing tools

A CRM rarely runs alone. Sales data has to agree with orders and invoices, calls and mail have to land on the right record, and marketing and billing need consistent contact status. Settle the data, direction, trigger and error handling for each link before choosing a platform, because connector coverage differs between SuiteCRM, EspoCRM and Twenty.

ERP order and account sync

Define which records cross between the CRM and the ERP, such as accounts, quotes, sales orders and invoice status. Decide the system of record for each field, because ERP systems like Odoo, ERPNext or a Fineract-based core will often own customer master data and payment status. Confirm whether the connector is a maintained package, a custom integration or a scheduled export, and ask how failed record writes are retried and reported.

Telephony and call logging

Map what the phone system sends and receives: inbound caller lookup, click-to-dial, call duration and recordings, and the activity record created for each call. Confirm the telephony provider's event format and whether call logs are written to the matching contact or left in an unmatched queue. EspoCRM publishes an official VoIP extension, so check its fit against your provider before assuming a custom build.

Email and calendar providers

Specify which mailboxes and calendars sync, in which direction, and whose consent or admin approval is needed for each account. Check how shared inboxes, bounce handling and meeting invitations are logged against accounts and opportunities. EspoCRM offers official Google and Outlook extensions, and Twenty lists email and calendar sync as a core feature, so verify both against your tenant policies and mail provider.

Marketing list and consent status

Decide which marketing tool owns subscription status and unsubscribe events, and how those flags reach CRM contacts. Confirm that opt-out changes made in the marketing tool reach the CRM quickly enough to stop outreach, and that campaign membership and engagement events are written back without duplicating contacts. EspoCRM offers an official MailChimp integration, so confirm it covers the list and consent fields you need.

Billing and payment events

Identify which subscription, invoice and payment events change CRM status, such as a renewal, a failed charge or a cancellation. Decide whether the CRM stores only the status or also the payment reference, and keep card data out of the CRM. EspoCRM offers an official Stripe extension, and Twenty's pricing page lists webhooks on all plans, so confirm the event list and how duplicate or out-of-order events are handled.

API, webhooks and error logging

List every inbound and outbound call the CRM must support, then choose the authentication method and the service account for each. EspoCRM supports API key, HMAC and basic authentication, with HMAC described as the most secure and basic authentication not recommended. Twenty exposes REST, GraphQL and webhooks. Require that every integration logs the payload, the result and the retry count, and that failures alert a named owner.

Questions that separate SuiteCRM, EspoCRM and Twenty

SuiteCRM is licensed under AGPL-3.0 for its SuiteCRM 8 core, and SuiteCRM 8.10.2 was published on July 31, 2026. The most consequential question is often the version path. Moving from SuiteCRM 7 to 8 is documented as a migration into a new environment, not an in-place upgrade, so a partner's plan for your existing instance matters more than any feature list. Authentication is another area to probe, since LDAP and SAML are configured through different switches and SAML logout behaves differently from what many identity teams expect.

Version path: Ask whether the partner will migrate a SuiteCRM 7 instance or start fresh, and how they will bring the 7 instance to the required 7.14.x level first. A good answer names a staging instance, file and database backups, and a review of customizations that may sit under the public/legacy folder.
Support horizon: Ask which release line they will deploy and how they will track patch releases. A strong answer explains that SuiteCRM 7.15 has security fixes until January 2028 and that no SuiteCRM 8 extended support release had been nominated yet, with a stated expectation of a nomination by Q3 2027.
Authentication: Ask whether they will use LDAP (AUTH_TYPE=ldap) or SAML (AUTH_TYPE=saml) and how they will handle directory groups. A good answer covers the logout gap, since IdP-initiated logout does not end the SuiteCRM session in the 8.7.0+ SAML implementation.
Stack and hosting: Ask for the PHP, Apache, MariaDB or MySQL versions they will support on your hosting. Confirm the current matrix against the compatibility documentation rather than accepting a version from memory.
Commercial support: Ask whether they will use vendor services such as SuiteASSURED or whether they will carry support themselves, and who answers when a patch release is needed.

Check that the candidate has migrated a SuiteCRM 7 instance and can describe the customizations they rejected or rewrote.

Operational requirements: hosting, upgrades, backups and support

This table compares the hosting, upgrade, backup and ownership requirements for SuiteCRM, EspoCRM and Twenty, with a verification step for each. Read each row as a question to settle before selecting a platform, since the stack and release cadence affect staffing and recovery plans more than feature lists do.

Requirement	What the platform asks for	Verification step
Application and database stack	SuiteCRM 8.10 runs on PHP 8.2 to 8.4 with Apache 2.4 and MariaDB or MySQL. EspoCRM needs PHP 8.3 to 8.5 and MySQL 8.0, MariaDB 10.6 or PostgreSQL 15. Twenty uses PostgreSQL and Redis.	Build a staging host from the exact versions in the current compatibility matrix and confirm the team can patch each runtime.
Background jobs	EspoCRM requires cron or a scheduled task for background jobs. Twenty runs a separate worker process alongside the server.	Confirm scheduled jobs and the worker run after a host reboot and that failures raise alerts.
Memory and sizing	Twenty's Docker Compose guide asks for at least 2 GB of RAM, since insufficient memory can crash processes. Sizing for SuiteCRM and EspoCRM depends on user count and integrations.	Load test with expected concurrent users and sync volume, then record memory and database headroom.
Backups and restores	Back up both files and the database together. EspoCRM's command.sh utility covers backups and restores in the script install. Customizations in SuiteCRM may sit in folders that migration can remove.	Run a timed restore into an isolated host each quarter and confirm record counts, attachments and login work.
Staging environment	The SuiteCRM migration guidance advises testing on staging, backing up files and database, and reviewing customizations first.	Rehearse every upgrade and migration on a copy of production data before a production change window.
Upgrade cadence	SuiteCRM 8 minor releases arrive roughly every eight weeks. Patch releases carry security and bug fixes only, with no database changes. EspoCRM and Twenty ship releases frequently.	Agree in writing which release tracks the client will follow and who applies patches within an approved window.
SuiteCRM 7 security window	SuiteCRM 7.15 receives security fixes until January 2028. No SuiteCRM 8 extended support release had been nominated, with a decision expected by Q3 2027.	Record the end date in the risk register and confirm whether a SuiteCRM 8 LTS release is named before committing to a version.
Monitoring and ownership	Someone must own patching, uptime, backup jobs and certificate renewal. Self-hosting moves these duties to the client or its implementation partner.	Document an owner for each duty, the on-call path and the alert thresholds, and review them after each upgrade.

How to turn the checklist into a signed requirements document

This sequence turns a loose list of CRM needs into a written scope that a platform choice, a partner and a budget can all be measured against. Each step produces a document or test result that the next step relies on, so the signed scope reflects how the business actually sells and serves customers.

Map current pipelines and fields with the team
Sales operations, customer success and support leads walk through how each deal, renewal or case moves today, including the stages, the fields people fill in by hand and the spreadsheets they keep alongside the CRM. A business analyst records the output as a pipeline map and a field inventory with owners and example values. The step is done when each team lead confirms in writing that the inventory matches how they work, and gaps are logged as open questions.
Classify each requirement as must-have or nice-to-have
The requirements owner and the business sponsor sort every item from the checklist into must-have or nice-to-have, with a one-line reason for each must-have tied to a process, a contract or a regulatory duty. Items that depend on a specific vendor feature are marked for confirmation rather than assumed. The output is a prioritized requirements register, and the step closes when the sponsor signs off on the must-have list.
Document retention and privacy rules with legal
Legal, compliance and the data protection lead define how long each record type is kept, which records must be exported or erased on request, which data is personal, and where it may be hosted. They also decide who may see sensitive fields and which communications must be preserved. The result is a retention and privacy schedule that the CRM design can be checked against, and the step is complete when counsel has reviewed it. Sector-specific rules, such as those in the financial services or healthcare sibling topics, should be confirmed here before design begins.
Run a trial import on each shortlisted platform
Take a representative sample of real accounts, contacts and opportunities, including messy duplicates and records with missing owners, and import it into a test instance of each shortlisted platform. Check how the import handles field types, relationships, duplicate matching and attachments, and record the errors and the manual cleanup each one requires. The output is a trial import report per platform, and the step is done when the team agrees which platform handles the sample with the least rework.
Test roles and record-level access on each platform
Build the role matrix from the requirements register, then create a test user for each role, such as sales representative, regional manager, support agent and auditor. Each test user attempts to view, edit, export and delete records in and outside their territory, and the results are logged against the expected behavior. Where a platform cannot enforce a rule as required, the gap goes into the register with a note on a workaround or a decision to accept it. The step closes with a signed access test report.
Confirm integration and authentication requirements
Engineering and IT list each integration the requirements call for, such as ERP, telephony, email and calendar sync, marketing and support handoffs, and the identity provider for sign-in. For each one, they confirm with the platform vendor or a test environment that the required capability exists, and note the data direction, frequency and owner. The output is an integration register with confirmed and unconfirmed items. Anything unconfirmed stays open until a test proves it.
Agree the scope in writing before build
The requirements owner compiles the register, the retention and privacy schedule, the trial and access test reports and the integration register into one requirements document. The business sponsor, the security lead and the implementation partner each review it, and the document records the chosen platform, the in-scope items, the open items with owners and the change process for later requests. Build starts only after all parties sign the document, because the signed scope is the baseline for the partner's written proposal.

CRM requirements questions buyers ask before hiring help

How long does CRM requirements gathering take?

The duration depends mainly on how many pipelines, integrations and data sources the CRM must serve, and on how quickly the business owners can decide. A team with one sales pipeline, one email system and a clean spreadsheet export will move much faster than a team with several regional pipelines, a telephony system, an ERP and a legacy database. Ask any partner to state the number of workshops, the named decision points and the written sign-off step before work starts, because those items determine the schedule. DeployOpen agrees timelines in the written scope before work begins, so the length of this phase is set there, not guessed in advance.

What does a self-hosted CRM project cost?

The cost depends on the scope you agree, not on a list price. The main components are configuration of pipelines, stages and custom fields, integrations with email, calendar, telephony and ERP, data import and deduplication, migration from an existing system, training for users and administrators, and ongoing support. Some of these are one-time (requirements, build, migration, training) and others recur (hosting, patching, upgrades, support retainers). Hosting and licensing costs vary with the platform you choose. For a quote, ask for each item listed separately, the assumptions behind each one, and which items are fixed scope versus estimated. DeployOpen does not publish a price list and produces a quote from the written scope.

Can a small team define CRM requirements and build it alone?

Yes, for a small scope, if the team has the right skills and time. A small CRM with a few pipelines, standard fields and one or two integrations is often within reach of a team with PHP or TypeScript experience and comfort with Linux, a database and web server. SuiteCRM and EspoCRM run on PHP with MySQL or MariaDB, and Twenty runs on TypeScript with PostgreSQL and Redis, so the existing stack usually decides which of these is realistic to operate. The work gets harder with role-based record access, SSO, email sync, migrations and compliance evidence. Ask the team to list who will own upgrades, backups and security patches after go-live, because that ongoing work is where internal builds usually strain.

What do we need to provide before a CRM partner starts?

A partner needs named business owners, real data samples and access to the systems the CRM must connect to. Name one owner for sales process, one for customer data and privacy, and one for IT administration, each with authority to approve pipelines, fields and access rules. Provide exports or samples from the current CRM or spreadsheets, including the fields people actually use, so duplicates and inconsistent values can be found early. Arrange access to the identity provider for single sign-on and group mapping, to the mailbox and calendar platform for sync, and to the telephony system if call logging is required. Confirm who approves the written scope and who signs off the final acceptance tests.

How do EspoCRM Cloud and Twenty per-user prices change as headcount grows?

Per-user prices grow linearly with headcount, so the gap between plans widens as the team expands. EspoCRM's pricing page lists EspoCRM Cloud at 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans (EspoCRM pricing). Twenty's pricing page lists Pro at 9 US dollars per user per month and Organization at 19 dollars per user per month, with Enterprise starting at 50,000 dollars a year (Twenty pricing). Its open source core can be self-hosted for free, which removes the per-seat fee but adds hosting and operations cost. Compare these figures against your own headcount forecast and against the self-hosting cost in the written quote.

Which requirements change the cost of building the CRM most?

Record-level access, integrations, migration and privacy rules usually add the most work. Role-based and record-level permissions take time to design and test, especially when regional teams or account territories overlap. Each integration with an ERP, telephony system or marketing tool needs its own mapping, error handling and monitoring. Migration from Salesforce, HubSpot or a legacy database requires field mapping, duplicate rules and post-migration checks. Retention schedules and data subject request handling need process as well as configuration. Ask a partner to name which requirements they consider fixed scope and which depend on discovery findings, so change requests are priced and approved in writing.

What should a CRM requirements document include before build starts?

A useful requirements document lists each pipeline with its stages and exit criteria, each entity and custom field with its owner and data type, the integrations with direction and frequency of sync, and the roles that control who can see and change which records. It should also record retention periods, privacy request handling, the reports leaders need, and the support handoffs between sales, marketing and service teams. Ask for a list of open decisions with named owners and due dates, plus a test plan that checks each requirement. Requirements that cannot be tested are a common source of rework after go-live, so require a testable statement for each one.

What a written CRM requirements scope should contain

A written scope for a self-hosted CRM should state, in one document, what is in scope, what is explicitly out of scope, how each requirement will be verified, what will be delivered, and what counts as accepted. The out-of-scope list matters as much as the in-scope list. For a CRM, it is where teams settle questions such as whether the first release includes Salesforce or HubSpot history, whether telephony is a live call integration or only call logging, and whether the ERP link covers invoices, customer master data or both. Each item should name the specific object, such as the opportunity stage model, the custom fields on the account entity, or the role that may export contacts, so that a later dispute can be checked against the document rather than memory.

Verification tests turn each requirement into a pass or fail check. Examples include a test that a sales user in one team cannot see another team's opportunities, a test that a duplicate contact import is caught by the agreed matching rule, a test that an inbound email is linked to the right account, and a test that a retention job removes records past the agreed period. Deliverables usually cover the configured instance, the data mapping workbook, the role and permission matrix, the integration specifications, user and administrator guides, backup and restore runbooks, and the handover session. Acceptance criteria then tie these together: which tests must pass, who signs off, and what happens to defects found after go-live. Ask the partner to show a sample scope and test plan before you commit.

Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list. A quote follows from the written scope, which is why the requirements in this checklist need to be specific enough to price. When you request quotes, ask each partner to state which items are one-time (configuration, migration, integration build, training) and which recur (hosting, patching, support, retainers), and to list the assumptions behind each figure, such as the number of integrations, the volume of records to import and the number of user roles. Any figure that a partner gives without a matching assumption is one to question.

How DeployOpen scopes, delivers and supports CRM requirements checklist work

DeployOpen turns CRM requirements into a written scope before any build starts, covering pipelines, entities, integrations, access rules and retention. We then implement the chosen self-hosted platform inside your own infrastructure, test it, document it and hand it over with ongoing support available as a retainer.

How we scope

Map current pipelines, stages and custom fields to the requirements agreed with sales, marketing and support leads.
Define the written scope for ERP and telephony integrations, email and calendar sync, and import and deduplication rules.
Record roles, record-level access, retention periods and privacy rights handling, with deliverables and timelines agreed before work starts.

How we build

Configure the selected platform's entities, fields, stages and permissions in a staging environment inside your infrastructure.
Build and test the agreed integrations, authentication method and reporting views against documented acceptance criteria.
Run trial imports and deduplication passes on sample data, then review results with the data owners before any production load.

How we hand over

Deliver configuration documentation covering stages, field definitions, permission matrices, integration mappings and retention settings.
Provide runbooks for backups, restores and upgrades so your team can operate the system after go-live.
Walk administrators through role management, access reviews and the evidence needed for internal or external compliance assessments.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope implementation closes.
Review platform release notes and plan upgrades or migrations against the agreed scope, such as major version changes.
Revisit requirements when sales processes, integrations or regulatory obligations change, with changes scoped in writing.

CRM requirements checklist