MT5 Setup and CRM Integration: Write Better Requirements
“Connect our CRM” is an intention, not an implementation brief. For an MT5 setup, the useful requirements describe the actions people need, the data involved, and the result they expect to see. This keeps a discussion about software products connected to an observable business workflow.
Choose one workflow at a time
Begin with a single action, such as a request for an agreed account category. Describe who starts it and what approval is required before any platform action. Separate the stages instead of treating a form submission, staff decision, and account creation as the same event. Each stage may have a different owner.
Define fields and their owners
List the information needed at each stage and identify where it is maintained. Agree how the platform account is linked back to the CRM record. Ask what happens when a required value is missing or changes later. Use example fields that reflect your actual process, not confidential client records sent through an enquiry form.
Specify visible status changes
Decide what staff should see when a request is pending, completed, rejected, or needs investigation. Clarify which states come from an actual platform response and which are internal workflow labels. A CRM should not present success merely because it attempted to send a request.
Agree acceptance and commercial scope
Turn the workflow into a small set of agreed checks, including the unsuccessful path. Identify who provides access, implements the connection, reviews the results, and supports it later. CRM integration and API access are optional at additional cost. An approved brief should explain the work being quoted without implying that every possible future workflow is already included.
Requirements as workflows with acceptance criteria
CRM requirements written as feature names are untestable. Write each as a workflow with a trigger, steps, outcome and acceptance criterion. Example: when a client uploads a document, the system stores it, sets the status to under review, notifies the reviewer queue and shows the client a pending message; acceptance is a test client seeing each state within an agreed time.
A list of ten such workflows is a better specification than a hundred feature names, and it lets you compare vendors on evidence rather than on claims.
A field ownership matrix
| Field | System of record | Written by | Read by | Notes |
|---|---|---|---|---|
| Client identity data | CRM | Portal, staff | Platform provisioning, reports | Sensitive |
| Trading login | Platform | Provisioning workflow | CRM, portal | Immutable once created |
| Account group | Platform | CRM workflow | CRM, reports | Changes logged |
| Balance | Platform | Platform | CRM, portal | CRM never writes except via balance operation |
| Payment status | Payment provider | Provider callbacks | CRM | Reconciled daily |
Every field needs exactly one system of record. Dual ownership is the root cause of most reconciliation problems.
Status model and visible state changes
Specify the state machine for each entity: lead, registered, documents pending, under review, approved, account created, funded, active, suspended. For each transition, define the trigger, the actor, the audit record and the notification. Make illegal transitions impossible, for example funding before approval.
Write the state model as a diagram and as a table. Vendors who cannot map their product onto your state model are telling you where customisation cost will appear.
Non-functional requirements
Beyond workflows, specify performance (time to create an account at expected peak), availability, backup and restore targets, retention, access control, audit logging and export formats. Each should be measurable. State the test method, for example "restore a backup into a test environment in under four hours and verify record counts".
Non-functional requirements are cheap to specify and expensive to retrofit, so include them in the first request for proposal.
Acceptance and commercial scope
Define acceptance as a set of test cases executed in a staging environment with expected results and evidence. Link each commercial milestone to a subset of cases. Separate included scope, optional scope and exclusions, and define how change requests are priced.
See our buyer’s guide for scoring and proof-of-concept practices.
Worked example: one requirement end to end
Take the requirement "a rejected document is resubmitted and approved". Specification: trigger is reviewer rejection with a reason code; the system sets state to documents requested, sends the client a message containing the reason and a resubmission link, preserves the earlier submission for audit and returns to the reviewer queue upon resubmission with a flag. Acceptance: in staging, a test client is rejected with a reason, receives the message within a defined time, resubmits and is approved; the audit trail shows both submissions and both reviewer decisions.
Written this way, the requirement can be demonstrated, tested and priced, and a vendor’s answer can be checked line by line.
Data migration and retention requirements
If existing client data must be loaded, specify the source format, mapping, validation rules and rejection handling. Specify retention periods by record type and the deletion or anonymisation process. State what must be exportable and in which format.
These requirements are often forgotten and surface late, when changing them is expensive. Include them in the first specification and test them in the proof of concept.
Prioritisation and traceability
Rank requirements into must, should and could, and give each an identifier. Trace each identifier to a test case, to a vendor response and to a contract clause. A traceability table is a few columns of a spreadsheet, and it answers three questions that otherwise cost days: was this requirement agreed, was it tested and who accepted it?
When scope changes, update the table first. A change request that cannot be linked to a requirement is either a new requirement, which needs prioritisation and a price, or a misunderstanding, which needs a conversation. Either way, the table keeps the discussion concrete and prevents the quiet growth of scope that makes projects late.
Frequently asked questions
How do I write testable CRM requirements?
As workflows with a trigger, steps, outcome and acceptance criterion, each verifiable in a test environment.
Why define a system of record per field?
To prevent dual ownership, which causes mismatches between CRM and platform.
What non-functional requirements should I include?
Performance, availability, backup and restore, retention, access control, audit logging and export.
How should acceptance be tied to payment?
Link milestones to executed test cases with evidence.