Low-code for ERP customization: SAP BTP and Dynamics guide

Yes — Power Platform can write data to SAP via the SAP ERP connector (available in Power Automate and Power Apps) and via custom connectors built on SAP's OData and REST APIs. The SAP ERP connector supports common transactional operations including creating and updating master data, posting documents, and triggering SAP workflows. For more complex write operations (posting complex financial transactions, updating batch-managed inventory), custom connectors calling SAP's BTP APIs or RFC function modules via the On-Premises Data Gateway provide greater coverage. Write-back governance is critical: citizen developer applications writing to SAP require careful testing with representative data volumes in a non-production SAP environment, as data integrity errors in ERP systems can have significant operational and financial impact. Limit citizen developer write-back to well-understood, low-risk transactions (status updates, approval confirmations) and require professional developer review for anything touching financial postings or master data creation.

Low-code extensions built on the platform layer (SAP BTP, Power Platform) are much more upgrade-resilient than traditional ABAP or X++ customisations because they interact with ERP through APIs rather than internal system objects. When SAP or Dynamics upgrades change internal data structures, ABAP/X++ customisations that reference those structures break; API-based low-code extensions only break if the API contract changes (which is much rarer than internal structure changes). SAP and Microsoft both maintain API backward compatibility through major versions with deprecation notices and migration paths. The practical implication: test your low-code extensions in a sandbox after an ERP upgrade before promoting to production, but expect the majority to work without modification. The API-first architecture of modern ERP low-code extensions is a significant upgrade resilience advantage over traditional customisation approaches.

SAP BTP licensing is complex and has evolved significantly: SAP Build Apps, Build Process Automation, and Build Work Zone are included in some SAP enterprise agreements (S/4HANA Cloud subscriptions include BTP credits that can be used for Build tools) and available as separate add-ons for others. SAP BTP uses a consumption-based model — BTP credits consumed by application usage, workflow executions, and API calls — which requires careful usage monitoring to avoid unexpected costs at scale. Microsoft Power Platform licensing includes Power Apps (per-user or per-app plans), Power Automate (per-user or per-flow plans), and Copilot Studio (session-based pricing). Power Platform premium connectors (required for some ERP integrations) require premium licences rather than the Microsoft 365-included base functionality. Both vendors provide licensing complexity that benefits from a licensing consultation before programme launch — engage your SAP or Microsoft account team to understand which tools are included in your current agreement versus requiring additional investment.

SAP provides structured learning paths for SAP Build citizen developers through SAP Learning Hub and the free SAP Learning platform (learning.sap.com). The SAP Build Apps Discovery Mission is the recommended starting point — it takes approximately 10 hours and covers the core SAP Build Apps concepts with hands-on exercises. SAP also offers SAP Build certification exams for citizen developers who want formal recognition of their skills. For enterprise rollouts, supplement SAP's self-paced content with internal training that covers organisation-specific governance (which APIs are approved, what data access is permitted, change control requirements) — generic SAP training doesn't cover organisation-specific rules. Running an internal hackathon as part of the launch (citizen developers build a real business use case within a structured event) is consistently effective at building both skills and enthusiasm simultaneously.

High-value, readily achievable low-code ERP automations across SAP and Dynamics: purchase order approval workflows (replacing email-based approval chains with automated routing based on amount and category, with approval links in mobile apps — typically saves 1–3 days per PO cycle); vendor invoice exception handling (automated routing of invoice exceptions to the right approver based on GL code and cost centre); new employee onboarding automations (triggering ERP provisioning steps from HR system events); expense report pre-validation (checking against policy before submission to ERP, catching common errors that cause rejections); and sales order confirmation notifications (automatically notifying customers and internal stakeholders of order status changes from ERP events). These use cases share characteristics that make them good citizen developer starting points: clear, finite scope; non-financial write-back (approval status updates rather than financial postings); easily testable outcomes; and significant time savings visible to the business team delivering them.

Authentication between Power Platform and SAP is handled via the On-Premises Data Gateway (for SAP systems in private networks) or SAP BTP API endpoints (for cloud-connected SAP systems). The On-Premises Data Gateway runs as a service in your network, acts as an authenticated bridge between Power Platform cloud services and on-premises SAP, and uses OAuth 2.0 or basic authentication credentials stored securely in Power Platform's credential management. For cloud SAP systems, OAuth 2.0 service principal authentication using SAP BTP's identity and access management is the recommended approach — service principal credentials rather than individual user credentials ensure the integration functions regardless of individual user availability. Never use shared named-user credentials for integrations — service principals with minimal required permissions, rotated on schedule, are the secure baseline. Azure Key Vault or SAP BTP Credential Store for secret management prevents credential exposure in flow definitions.

Yes — many organisations operate both platforms in parallel, using each for different use cases based on which system the automation touches most deeply. The common division: SAP BTP tools for SAP-centric processes (automations that read and write SAP data, SAP-native UI extensions, SAP workflow integrations); Power Platform for Microsoft 365-centric processes (automations involving SharePoint, Teams, Outlook, Dynamics 365) and for citizen developer programmes in non-technical business units where Microsoft tools are more familiar. The overlap use case — automations that span both SAP and Microsoft systems — can be built in either platform with the appropriate connector to the other system. The governance challenge of running two low-code platforms simultaneously is real: separate toolchains, training paths, and CoE governance. Most organisations address this by designating one platform as primary and the other as secondary, with clear guidance on which to use for which category of automation.

Low-code ERP integrations have meaningful performance limitations compared to native ERP functionality: API-based integrations add latency (100–500ms per API call vs microsecond in-process ERP operations); Power Automate flows have execution limits (actions per day, concurrent executions) that can constrain high-volume automations; and low-code platforms typically batch-process rather than stream ERP events, introducing latency in event-driven automations. These limitations are acceptable for the majority of citizen developer use cases (approval workflows, data entry forms, periodic reports) which are not latency-sensitive. They become problematic for: high-volume batch processing (thousands of records per minute), real-time operational dashboards requiring sub-second latency, or integrations in critical path of ERP transactions. For these use cases, professional development using native ERP APIs, ABAP/X++ batch programs, or ERP-native workflow tools provides better performance. Evaluate performance requirements upfront and route high-performance requirements to professional development from the start rather than discovering limitations after citizen developer investment.