Connecting business applications and CRM

My contribution

Application development, web services, integration and operational support.

Context

Institute and Faculty of Actuaries; member-facing applications and CRM integration.

Delivered capability

CRM-backed application functionality and queues for transaction updates.

The business problem

A member-facing application is only part of the service. Information held in CRM and functionality delivered by other systems need to be available in the right context for members and staff.

My work has included Drupal applications and custom integrations, as well as presenting Dynamics-backed information through DNN applications and forms.

My contribution

I developed application functionality and worked on web-service integration and support. I also contributed requirements and technical input during wider systems change. I worked alongside the teams and suppliers responsible for the connected platforms.

Keeping CRM processing off the critical path

At the IFoA, I built queue systems to update transactions in CRM without making the platform wait for CRM processing. This separated the timing of those updates from the immediate application workflow, so the CRM would not hold back the platform.

My wider support work has covered both Integra and Dynamics. Queued processing is a practical performance decision: it changes when an update completes, so the application and its support processes need to account for that boundary.

How I think about the integration

I start with the business operation: which information is needed, which system owns it and what an application is allowed to change. A successful API response needs to be interpreted alongside the actual business state. Where several systems participate, a partial update needs a visible recovery path.

How I evaluate integration decisions

When extending an existing application, I consider whether a rule belongs in the web layer or in the system that owns the information. Repeating the same rule in several places can make future changes harder to support. Moving every concern into a new service also adds a dependency. The appropriate boundary depends on the actual API contract and operational ownership.

Outcome and evidence

The work connected web application functionality with CRM information. The transaction queues separated CRM updates from immediate application processing, allowing those updates to complete independently of the user-facing workflow.

A public example of my integration work

The earlier Edubase integration for New Schools Network shows custom API validation alongside Drupal’s existing forms, publishing rules and error reporting.

Technical deep dive: when the API succeeds but the process fails