Pro-Code Extension Vocabulary — Low-Code & No-Code Exercises

1 / 5

A Power Platform architect explains to a business team: "To integrate with your legacy ERP, we'll need to build a custom connector — none of the standard connectors can reach it." What is a custom connector and when is it required?

Custom connectors are the pro-code bridge between the low-code world and any API that doesn't already have a Microsoft-provided connector — understanding them is essential for any fusion team working with enterprise systems.

When a custom connector is required:
• Internal APIs (your own microservices, internal data platforms)
• Legacy systems with custom APIs (ERP, LIMS, proprietary line-of-business systems)
• Third-party APIs not covered by the 900+ existing connectors
• Standard connector exists but doesn't expose the specific endpoint you need

What building a custom connector involves:

Step	What you do
1. Define the API	Provide an OpenAPI 2.0 (Swagger) definition or import from Postman collection
2. Configure auth	Set up OAuth 2.0, API key, Basic Auth, or Windows Auth
3. Define actions & triggers	Map each API endpoint to a named action with friendly labels visible to makers
4. Test	Validate each action works with real API credentials in the connector tester
5. Share	Share the custom connector with makers in specific environments or the entire tenant

Governance note: Custom connectors require a Premium license for all users of any flow that uses them. The CoE must assess each custom connector for security and data classification before sharing it tenant-wide.

Key vocabulary:
• Custom connector — a developer-built Power Platform integration wrapper for any REST/SOAP API
• OpenAPI (Swagger) — the industry-standard format for describing REST API endpoints; used to define custom connectors
• Fusion team — a team combining professional developers (who build custom connectors) and citizen developers (who use them in flows)
• Pro-code extension — custom development that extends the capabilities of a low-code platform beyond its out-of-the-box limits

2 / 5

A developer is asked to create an interactive data grid that displays and edits records in a model-driven Power App. The designer suggests using a PCF control. What is a PCF control and why would it be used here?

PCF (Power Apps Component Framework) enables professional developers to extend the Power Apps UI without leaving the platform — it is the primary pro-code capability for building enterprise-grade interfaces in model-driven apps.

PCF component anatomy:

File	Purpose
`index.ts`	Main TypeScript component logic and lifecycle methods (init, updateView, destroy)
`ControlManifest.xml`	Declares input/output properties, data-set bindings, and platform capabilities required
`css/`	Scoped CSS styles for the component
React files (optional)	For React-based "virtual" PCF components — lighter weight, recommended for new components

PCF component types:
• Field components — replace the default control for a single column/field (e.g. a custom address picker instead of a text field)
• Dataset components — replace the default grid/list view for a table of records (e.g. a custom interactive Kanban board)

PCF in a model-driven app context:
PCF is particularly valuable in model-driven apps where the standard form controls are limited; professional developers build a PCF control once, publish it as a solution, and citizen developers can then configure and place it on any form through the form designer with zero code.

Key vocabulary:
• PCF (Power Apps Component Framework) — framework for TypeScript/React custom UI components in Power Apps
• Model-driven app — a Power Apps app whose structure is driven by the Dataverse data model rather than canvas layout
• Canvas app — a Power Apps app built with a pixel-perfect designer; fully flexible layout
• Control manifest — XML file declaring a PCF component's inputs, outputs, and required capabilities

3 / 5

A platform architect presents the following decision matrix: "We use pro-code when the requirement cannot be met within the platform's native constraints — otherwise citizen developer low-code is preferred." What defines a "pro-code threshold" and how should teams decide when to cross it?

The pro-code vs low-code threshold decision is one of the most important architectural judgements in modern enterprise platform engineering — making it poorly leads to either over-engineered simple automations or under-powered critical systems.

Decision framework — use pro-code when:

Requirement	Pro-code alternative to low-code
Custom UI beyond PCF capability	React/Angular app embedded via iframe or published separately
Complex data transformation	Azure Function called from Power Automate via HTTP connector
High-throughput processing (>100k records)	Azure Data Factory or Databricks pipeline
Latency-sensitive real-time API	Azure API Management + Azure Function
Advanced ML/AI business logic	Azure ML endpoint called from Power Automate

The "fusion team" model:
The best practic is not an either/or choice — it is a fusion: citizen developers build the flow orchestration in Power Automate, while professional developers build the custom connectors, Azure Functions, and PCF components that extend the platform's capabilities at the edges. This maximises developer productivity and keeps citizen developers in the loop.

Anti-patterns at the threshold:
• Rebuilding a simple approval flow in Azure Logic Apps because "pro-code is more robust" — wastes 5× the time for the same result
• Building a real-time financial calculation engine in Power Automate expressions — hits platform limits, becomes unmaintainable

Key vocabulary:
• Pro-code threshold — the point at which low-code platform limits are reached and custom development is required
• Fusion team — mixed team of citizen developers and professional developers collaborating on a low-code solution
• Azure Function — serverless compute; the primary pro-code extension point called from Power Automate for complex logic
• Over-engineering — applying more complex solutions than the problem requires, increasing cost and maintenance burden

4 / 5

A Power Platform architect creates a deployment pipeline and packages everything into a solution before deploying to the production environment. A junior developer asks: "What is a solution and why can't we just click Publish directly?"

Solutions are the fundamental unit of Power Platform ALM — without solutions, deploying changes across environments is a manual, error-prone process that enterprises cannot scale.

What can live inside a solution:

Component type	Examples
Apps	Canvas apps, model-driven apps, Power Pages sites
Flows	Cloud flows (Power Automate), desktop flows (Power Automate Desktop)
Data	Dataverse tables, columns, relationships, choices
Connectors	Custom connectors, connection references
Configuration	Environment variables, security roles, AI Builder models

Managed vs Unmanaged solutions:
• Unmanaged: used in DEV; components can be edited directly; not suitable for deployment to higher environments
• Managed: deployed to TEST and PROD; components are locked against direct editing; ensures changes flow through the pipeline and are never made directly in production

Why "just click Publish" fails at scale:
• Changes made directly in production leave no deployment trail
• Cannot roll back easily when a change breaks something
• Other team members' changes in DEV may overwrite production changes
• Environment-specific settings (connection strings, SharePoint URLs) would target the wrong environment

Key vocabulary:
• Solution — a versioned, deployable container of Power Platform components for ALM
• Managed solution — a read-only deployment to test/production environments; components cannot be directly modified
• Unmanaged solution — a development-mode solution where components can be freely edited
• Solution layering — multiple solutions installed in the same environment, with upper layers overriding lower-layer settings

5 / 5

A solutions architect poses this question to the team: "Should we implement this real-time pricing logic in Power Automate, or should we create an Azure Function that Power Automate calls?" How should the team frame this decision?

The Power Automate vs Azure Function decision is a recurring architectural conversation in any organisation using Power Platform — framing it correctly by technical requirements (rather than preference) is a mark of platform architecture maturity.

Capability comparison:

Capability	Power Automate	Azure Function
Complex calculations	Limited (expression language)	Full programming language
External libraries	Not supported	Any NuGet/npm package
Cold start latency	Seconds (cloud flow startup)	Milliseconds (with premium plan)
Throughput	Action limits apply	Auto-scales to millions of calls
Testability	Limited; requires platform test tools	Full unit testing with standard frameworks
Multi-channel reuse	Power Platform only	Any client via HTTP

The "best of both" pattern for pricing logic:
① Azure Function: accepts pricing inputs (SKU, quantity, customer tier), applies complex business rules using a financial library, returns a typed JSON response in <50ms
② Power Automate: handles the orchestration — collects form input, calls the Azure Function via HTTP connector, stores the result in Dataverse, sends approval if discount exceeds threshold

This pattern gives you: Full computational power + full low-code governance + testability + reusability across channels

Key vocabulary:
• Azure Function — serverless, event-driven compute that runs custom code; the primary pro-code extension point for Power Automate
• Orchestration vs computation — Power Automate owns orchestration (flow control); Azure Functions own computation (business logic)
• Cold start — the delay when a serverless function starts for the first time after being idle; mitigated with Premium plan "always on" setting
• Auto-scaling — serverless compute automatically provisions additional instances to handle concurrent requests without manual configuration