We’ve shown you the concept. The roles. The flows. The tech stack. Now let’s talk about how this actually lands in enterprise.
The simple Steve logs into an external portal. Rents recipes. Publishes tenders to print from manufacturing vendors. Monitors production and delivery status. All from the portal interface.
Works great.
But enterprise Steve, the one working at Equinor, IKEA, or Siemens -+doesn’t just browse marketplaces. Enterprise Steve has:
- An ERP system
- A CRM system
- Procurement workflows
- Approval chains
- Compliance requirements
- IT policies
Enterprise Steve needs CraftPortal connected to his world. His tenant. His systems. His processes.
The ISV package bridges these two worlds. Customer data stays in customer tenant. CraftPortal handles the marketplace, IP Owners, Manufacturers, the recipe catalog.
No workflow fragmentation. No copy-paste between systems. No “let me check the other portal.” One flow. Connected.
What Customer Get
Power Platform Components

| Component | CraftPortal Examples |
| Tables | Tenders, Recipes, Vendors, Manufacturers, Bids, Projects, Parts |
| Dashboards | Tender Overview, Production Status, Vendor Performance |
| PCF Widgets | Recipe Viewer, 3D Model Preview, Status Tracker |
| Power Automate templates | “New Tender → Notify Vendors”, “Bid Awarded → Create Project”, “Part Printed → Update Inventory” |
| Security Model | Roles: Procurement Manager, Vendor, Manufacturer, Viewer |
What We Get
- AppSource listing = discoverability, Microsoft co-sell, enterprise credibility
- Do this right and CraftPortal becomes invisible infrastructure — always there, impossible to replace
That’s not a customer. That’s a permanent relationship.
The tech stuff

Our ISV package includes two data integration flows. Custom Connector for on-demand requests — direct calls to CraftPortal API when you need real-time actions. Cached Core Data for near real-time sync — we push core data into the customer’s environment via Azure EventGrid into Azure SQL and Dataverse. Why both? Cached data enables full delegation in Power Apps. No query limits. Instant performance. Citizen developers query local tables instead of external APIs. CraftPortal data that feels like their own.
The Code
Azure Function Trigger & Interface


Trigger Type
1) HTTP-triggered Azure Function (API Gateway)
- Used for synchronous operations and for publishing events
- Secured via Azure AD authentication

2) Event Grid–triggered Azure Function (Event Processor)
- Subscribes to Event Grid topic events
- Processes vendor integration asynchronously
- Updates Dataverse with final status/result

Interface Characteristics
- REST-style endpoints
- JSON request/response payloads
- Versioned route (example):
/api/v1/vendor/operation
The Release
Power Platform Environment Strategy

Source control strategy
Repo structure (example)
- /solutions/<SolutionName>/ (exported source using Power Platform CLI/PAC)
- /pipelines/ (YAML for CI/CD)
- /tests/ (integration test scripts, Postman collections, Playwright scripts, etc.)
- /docs/ (release notes templates, runbooks)

CI Pipeline

CD Pipeline

Building the ISV package deliverable
An ISV-style deliverable usually includes:
Managed solution ZIP(s)
- Core solution (managed)
Installation guide
- Required licenses and prerequisites
- Import steps
- How to set environment variables
- How to create/bind connections
- Security roles to assign
Configuration workbook
- List of env vars, defaults, required values
- Connection references mapping
- Any URLs/endpoints
Release notes + known issues
- What changed, what to verify
Support / troubleshooting
- Common import errors
- How to re-run failed flows
- Health check steps

Infrastructure as a code
In our solution, we are using both managed power platform ISV and dedicated cloud infrastructure for them.
It means that each customer should deploy his own Azure infrastructure to unlock Power Platform solution distributed via the AppSource.
We are introducing it via the one click Azure infra deployment process. Model driven app has dedicated admin App which is Allowing user run call the deployment by himself after the main package installation.

Deployment

Note: The selection of the resourcegroup is not part of the BICEP / ARM template. It expects a resource is available. This selection is provided by the portal.
To support that scenarios, We need to provide the all the required bicep files, which are the blueprints for the Azure Services.
Benefits of Bicep
Bicep provides the following advantages:
- Support for all resource types and API versions:
- Orchestration
- Repeatability
The following examples show the difference between a Bicep file and the equivalent JSON template. Both examples deploy a storage account:

Directory Structure

Deployment.
We are using couple of Docker compose files for prod and dev deployment.
It allow us simplify the infrastructure for the local development setup.

Keep in mind that the main rule of using docker-compose: No sensitive data should be hardcoded inside, all environment specific details must be placed to the .env file.


We are following a classic approach with private azure docker registry (ACR) to store frontend and backend docker images.
How to convince IP Owners?
The idea behind is receive all the benefits of owning the infrastructure + extra features of the Platform owner(LogiQraft) like dedicated, specifically designed AI services, Proactive monitoring system, etc…
To make it work, we are using Azure Lighthouse + Managed Identity.

How it works:
- The customer delegates a scope (subscription / resource group) to you via Azure Lighthouse.
- Your identity in your tenant (this can be:
- a Managed Identity, or
- a service principal/app)
is granted a role on their resources through that delegation.
- You then query their Application Insights / Log Analytics data using your identity, and Azure enforces the delegated RBAC.
Why Lighthouse is ideal:
- No need to create/maintain identities in every customer tenant
- Customers can revoke access easily
- Scales across many tenants
- We assume that IP Owners would be careful to share their IP and by following this approach we are addressing their concerns
Categories: Redstone Realm , Governance & Best Practices , Code Connoisseur , Digital Transformation
Badges: Power Of The Shell, ACDC Craftsman, Plug N’ Play