B2B customer portal development in Baku starts with a decision more important than the visual interface: which system is authoritative for each piece of business data. A portal can give customers one place to see orders, invoices, balances, contracts, documents and service requests. But if it becomes an unmanaged copy of the CRM, ERP or accounting system, teams soon face conflicting figures, stale records and manual corrections.
The practical goal is an operational platform, not a second system of record. The portal authenticates the user, applies their organisation and role permissions, presents only the information they are entitled to see, and routes actions to the system that owns the underlying business record. That distinction should be agreed before a development proposal is scoped.
Start with a system-of-record map
A system of record is the final authoritative source for a particular data domain. The portal may retain operational data of its own, but it should not silently become the master for everything. In a typical B2B architecture, ownership may look like this:
- CRM: companies, contacts, account ownership, opportunities and sales terms.
- ERP: products, orders, fulfilment, delivery, price rules and contract execution.
- Accounting: invoices, payments, credit notes, receivables and financial posting periods.
- Document management or storage: signed agreements, certificates, delivery acts and supporting files.
- Portal: portal identities, organisation membership, notification preferences, access logs and portal-specific workflow states.
For every object, document a simple rule: what can a customer read, create, request, approve or amend in the portal, and where is the resulting change committed? For example, a buyer can view an ERP order but submit an address-change request through the portal. The request may require internal approval before the ERP order is updated. The portal coordinates the request; it does not create an uncontrolled competing order record.
Choose deliberately: expose, synchronise or orchestrate
There is no single integration model for all data. A sound customer portal development Baku proposal should identify which model applies to each capability rather than promise generic “CRM and ERP integration.”
Expose data from the owner
With an expose model, the portal retrieves data from the source system at request time through an API or service layer. This is useful for data that must be current, such as an order status, available credit or latest invoice balance. It minimises duplicate data, but makes portal responsiveness dependent on the source system.
Define timeouts, caching rules and the user experience for an unavailable dependency. “No orders found” is materially different from “order information is temporarily unavailable.” Where a source is slow, the portal can show a clearly labelled recent snapshot while it refreshes, if that is appropriate for the business risk.
Synchronise a controlled read model
With synchronisation, the portal holds a limited, purpose-built copy of data it needs for fast dashboards, search or resilient read access—for example, invoice metadata for the past 24 months and order summaries. This is often appropriate when direct ERP queries are expensive or when users need cross-system search.
Synchronisation is not a reason to allow two systems to edit the same commercial values. Display the last successful update time, define an acceptable freshness target, retain a way to reprocess failed changes, and make the owner system clear. Customer write actions should usually be sent as commands to the owner rather than editing the replicated record locally.
Orchestrate a cross-system workflow
Orchestration is required when one customer action triggers a controlled sequence across several systems. A customer may accept a quote; the portal checks their authority, updates the CRM opportunity, asks the ERP to create an order, requests a document from a storage service and reports the outcome.
The portal may own workflow states such as submitted, processing, completed and needs attention. Those are integration states, not replacements for the ERP’s financial or fulfilment state. Keeping that distinction prevents a dashboard label from being mistaken for an accounting fact.
Permissions must protect every object, not just the navigation
A B2B account represents an organisation, often with branches, legal entities and multiple user types. A finance user may need invoices; a purchasing manager may create orders; an executive may see consolidated information; an external auditor may be limited to a specific document set. The access model therefore needs more than broad “admin” and “user” labels.
Define access using at least user, organisation, role, scope and action. Scope can include subsidiary, branch, contract, project or account. Each API request must verify that the current user can perform the requested action on the specific object, even if the object identifier is technically valid. OWASP identifies broken object-level authorisation as a major API risk; property-level filtering also matters so an otherwise permitted invoice response does not reveal internal notes, bank details or fields irrelevant to that role.
Role matrices, exception journeys and admin flows should be designed before implementation. POLADO’s UI/UX & Product Design service can turn those rules into testable customer and staff flows; our Web Platforms & Applications service can then implement the platform and integration boundaries.
What a secure document portal needs beyond file links
A secure document portal should treat a file as a governed business object, not an attachment on a public URL. Its catalogue should record the document type, related organisation, contract or order, version, publication date, visibility policy and audit events. The file can remain in protected storage while the application issues a short-lived download link only after it has evaluated access.
- Validate organisation, branch and contract context for every document request.
- Use immutable identifiers and explicit versioning; make “latest version” a business rule, not an overwritten file.
- Audit views, downloads, uploads, approvals and deletions.
- Set session expiry and reauthentication requirements according to the sensitivity of the action; consider MFA for privileged or high-risk access.
- Revoke active access promptly when a customer contact is deactivated or their organisation relationship changes.
NIST guidance emphasises protected session handling, clear logout mechanisms and appropriate session timeouts. In practice, the portal should also help support teams answer access questions without exposing why another organisation or individual has access.
Design for integration failure before it happens
ERP maintenance windows, API timeouts, duplicated requests, merged CRM records and incomplete webhooks are normal operating conditions. A credible CRM ERP integration Baku plan includes the following controls:
- Identifier mapping: define how portal, CRM, ERP and document IDs relate, including mergers and archived records.
- Idempotency: retrying “create order” must not create a second order.
- Retry policy: distinguish transient failures that can retry automatically from business exceptions requiring review.
- Exception queue: failed messages must be retained, visible and assigned—not lost in application logs.
- Reconciliation: compare the portal’s processed commands and expected outcomes with the owner system on an agreed schedule.
- Truthful status messages: “request received” means the portal stored the command; “completed” should mean the owner system confirmed the result.
A transactional outbox pattern and idempotent consumers are common ways to make asynchronous messaging more reliable, but tools alone are not the answer. The proposal should state who receives alerts, who corrects an exception, which changes may be replayed and how the customer is informed. Ongoing observability, safe releases and incident ownership can be planned through POLADO’s Technical Support & Consulting service.
Questions to answer before requesting a proposal
- What are the three to five highest-value outcomes for the first release: order visibility, document exchange, invoice access, service requests or repeat ordering?
- Which application owns each data type, and what freshness is acceptable to customers and staff?
- Does each existing system provide an API, webhook, export file, database access or only a manual workflow?
- How are customer organisations, legal entities, branches and contacts related?
- Which documents and fields are commercially, financially or legally sensitive?
- Which customer actions are immediate, and which require staff approval?
- When an integration is unavailable, who is notified, who resolves it and what does the user see?
- What audit, retention, export, deletion and account-offboarding requirements apply?
Build the portal as a controlled access layer
A successful client portal software development project reduces email chains, spreadsheet exchanges and status-chasing calls because it gives each authorised customer user a dependable route to business information and actions. It does not achieve that by copying every backend table into a new interface. It succeeds by making ownership, permissions, documents, workflows and recovery paths explicit.
POLADO plans B2B portals as integrated products with defined operational responsibilities—not simply logged-in pages. If you are evaluating a portal for CRM, ERP, accounting or document workflows, request a consultation through our Web Platforms & Applications service to map the systems of record and shape a buildable first release.