Low Code in Financial Services, Part 3: A Practical Example of Internal Workflow Transformation

In our first article in this series, we explored some of the common IT challenges at banking organizations as users and teams work within strict rules and boundaries that safeguard centralized systems that typically have complex architectures and slow-moving development pipelines. In part 2, we looked at how each of the key Power Platform services can align with the needs of a bank, both at the individual service level to offer better solution capabilities and as an overall platform choice that aligns with mature enterprise architectures.

In this final piece in the series, I would like to make this perspective more concrete. Consider a common scenario I’ve encountered across banking organizations: an internal request intake and approval process.

This capability could be needed for onboarding requests, access provisioning, operational approvals, or internal service requests, all of which are high-volume, process-driven, and critical to day-to-day operations.

Traditional Approach

In a typical setup, building such a system follows a full engineering lifecycle:

• Custom UI development for request intake
• Backend services to manage business logic
• Integration layers to connect with internal systems
• Database design for storing request and audit data
• Reporting solutions built separately

And it requires the involvement of a range of people involved in areas including frontend and backend engineering, integration, infrastructure and deployment pipelines, and testing and release management. 

Even for relatively straightforward workflows, the process must go through:

• Requirement gathering and documentation
• Sprint planning and prioritization
• Development and QA cycles
• Deployment approvals

As a result, delivery timelines typically range from 8 to 12 weeks for initial rollout. From an architectural standpoint, a solution like this will be robust, but often over-engineered for the problem being solved. And over time, additional challenges emerge. Enhancements require re-engaging engineering teams. Change requests compete with higher-priority initiatives from across the organization. And knowledge related to the solution can become concentrated within specific developers.

This creates a system that works, but is slow to evolve and difficult to sustain.

Power Platform Approach

Now consider the same use case implemented using Power Platform as a governed extension layer.

The architecture is intentionally simplified while still aligning with enterprise controls: