Tag Archives: low code

Final Submittion – OUR JOURNEY AT ACDC 2O26

Posted on by

Problem statement: We came to ACDC Hackaton 2026 with an ambition to solve the problem that exist in supply chain, that affects everyone involved. Global spare-parts supply chains are slow, fragile, carbon-heavy, and often fail when parts are obsolete, or manufacturers no longer exist.

Original Solution we wanted to build: CraftPortal replaces shipping with digital “crafting,” using AI and cloud technology to match, recreate, and produce parts locally- fast, resilient, and sustainable. It was, however, focused on the idea from ou perspective and plan to refine this concept during the hackathon.

Evolution Journey: and then happened why we love ACDC Hackaton for.

– “Put the Customer in focus”, said Sara on the opening day, our beloved judge on Digital Transformation category.

So, we worked on the idea to enrich our web application solution to include the ISV package and give our potetial customer with UI and UX they recognize well, namely M365, Power Platform, BizApps.

– “I love your futuristic concept…” said Mikael from Redstone Realm perspective and inspired us to combine Microsoft 365 / Dynamics 365, SharePoint, Teams, and Azure

“Simple code screenshot is not enough, show me how it solves your problem”, noted Keith (Code Connoisseur),  and we challenged the status Quo and wanted to generate bigger impact…. So what we did is

“Turn data into insights….”, reminded Cathrine from Data, AI and Analytics, and we revised our data model focusing to build a solid fondation for our solution, so we could start to map external data sources and motiveted us to explore RAG.

“Everything you have there has to be there for a strong reason” warned us Fredrik from Low-Code angle in the start, and we critically reviewed our ecosystem to follow strict focus on the power of the low code.

“No security holes” declared Scott on Governance and Best Practices and you don’t mess with Scott. No fluff, we need a proper best practice focused ALM and Governance for the whole application.

As a result of continued brainstorming during these 3 days, and dialogue, our refined Solution started to look like this: … scroll down:)

DIGITAL TRANSFORMATION

The Concept

Supply chains are slow, fragmented, and carbon-heavy. Parts ship across the world when they could be printed locally. CraftPortal changes this – a marketplace where recipes travel through the portal, parts get made nearby. Faster. Greener. Smarter.

Customer needs a part. Can they print it? Yes – browse marketplace, select blueprint from IP Owner, print, deliver. No – publish a tender, receive bids from Manufacturers, select, award, contract, they print, deliver. Two paths. Same portal.

We built two paths to CraftPortal. A SaaS web application for users who want to jump straight in. And an ISV package for customers who want CraftPortal wired into their Microsoft 365 environment.

Users choose: Web App or Power Apps:

Customers who prefer Model Driven App get a clean, familiar UI – the Power Apps experience they already know, tuned for digital inventory workflows:

But they can surely use our fancy web app. Vendors – IP Owners and Manufacturers – use the Portal interface. They browse public tenders, submit bids, upload recipes, manage contracts, track orders. All through Power Pages.

Value & Monetization

CraftPortal sits in the middle of every transaction. Recipe rented? We’re there. Part printed? We’re there. That’s the value.

Monetization options:

  • Subscription – monthly/annual access to the platform
  • Transaction-based – percentage per recipe rental, per tender, per print job

Or both. Base subscription for access, transaction fee for volume.

LOW-CODE

Low-Code: The Redstone Behind CraftPortal

We built CraftPortal in 3 days. A marketplace. Tender flows. Vendor management. Document automation. AI agents and Power pages portal. How? Low-code.

The Building Blocks are as follows:

Power Pages for the Portal. Model Driven Apps for back office. Power Automate for every flow. Copilot Studio for autonomous agents. Dataverse for data. Generative Pages for dashboards.

We wired it together with clicks, not code.

The Low-Code Highlights

  • Autonomous agents – Copilot Studio detects Dataverse changes, posts to Teams, triggers RPA
  • RPA integration – Power Automate Desktop opens Bambu Lab Studio and clicks Print.
  • Teams + SharePoint + Dataverse – Fully automated channel and document location creation via Power Automate
  • Generative Pages – KPI dashboard pulling live Dataverse data
  • OneFlow contracts – Power Automate creates and sends contracts for signature
  • Link Mobility SMS – Automated bid notifications
  • Custom Connectors – ISV package API integration
  • FetchXML Builder – Low-code query generation (we click buttons, it writes XML)

Deep Dives

Want the details? We documented everything here:

The Result

A full digital inventory platform. Built by a small team. In 3 days. Low-code made it possible.

CODE CONNOISSEUR

Low-code gets you far. But sometimes you hit a wall – a custom UI that doesn’t exist, real-time updates that Power Automate can’t handle, or an API that needs to be built from scratch. That’s when we switch gears. Pro-code fills the gaps.

We have various code projects and components in our solution:

  1. PCF Control. That allows customers to order the appropriate equipment that should be printed. Client Side Salsa | Arctic Cloud Developer Challenge Submissions
  2. Power Pages Portal. That manages turning basic Minecraft resources into different tools and help clients to find an appropriate vendor for printing adapts to all devices and screen sizes. Chameleon | Arctic Cloud Developer Challenge Submissions
  3. Web Portal for the 3D printer. Using this custom local web portal we manage our printer device. Crafting, Crafting, Crafting…. Category: Pro Code  | Arctic Cloud Developer Challenge Submissions
  4. Model builder app – which is helping customer recover lost recipes from the single shot; Right now – bring real-time data to the app | Arctic Cloud Developer Challenge Submissions
  5. Azure Function – used to communicate with the external vendor API. ISV Package – the missing link | Arctic Cloud Developer Challenge Submissions

DATA, AI, ANALYTICS

The Dashboard

Our CraftPortal KPI Dashboard brings it all together. Built with Generative Pages and React, pulling live data from Dataverse:

  • Summary cards – Total Projects, Open Projects, Total Bids, Wandering Traders
  • Project Status Distribution – Donut chart showing lifecycle states
  • Bid Conversion – Submitted vs selected bids
  • Win Rate by Trader – Performance leaderboard
  • Projects per Month – Trend analysis over time
  • Top Wandering Traders – Gamified rankings

Light mode. Dark mode. Minecraft item icons from the official API. Business intelligence with a blocky twist.

We built the foundation. Dataverse as our core. Power BI dashboards for KPIs – tender status, bid conversion, vendor performance, projects per month. Live telemetry streaming from our IoT-connected Crafting Tables via Azure IoT Hub. Real-time monitoring of print jobs, temperatures, and device health.

Last year we went deep on Microsoft Fabric – Medallion architecture, Data Activator triggers, the whole pipeline. We didn’t want to repeat ourselves.

The Vision

The vision was fun: a custom Knowledge-based Copilot powered by Fabric. Pull external data from the official Minecraft API (GitHub – PrismarineJS/minecraft-data: Language independent module providing minecraft data for minecraft clients, servers and libraries.)

via Azure Data Factory. Deploy a proper RAG pipeline – chunking strategies, metadata filtering, semantic search, hybrid search, custom retrievers. Debunk RAG the right way.

Unfortunatley, we barely finished the data platform in time. The RAG adventure stays on the roadmap.

Sometimes three days isn’t enough. But the foundation is solid. The diamonds are waiting to be mined.

GOVERNANCE & BEST PRACTICES

Essence

Our goal during the hackathon was to show the complex implementation of the project with different aspects of the implementation.

When it comes to even the industry focus switched to AI related topics it still requires advanced level of the solution design to enable existing services for the LLM.

That is why we mentioned advanced level technologies such as: Azure Local, Lighthouse, and IoT Hub.

At the same time complex solutions usually require more effort for implementation. By following best practices of each piece of that puzzle, we are increasing the overall success rate of the delivery. ISV Package – the missing link | Arctic Cloud Developer Challenge Submissions

REDSTONE REALM

We created our business solution using Microsoft technologies - Open AI, Azure DevOps LLMs, Azure Function, Outlook and Microsoft teams. Check out the article ISV Package – the missing link | Arctic Cloud Developer Challenge Submissions

By deliberately meeting and exceeding every requirement across Digital Transformation, Low-Code, Pro-Code, Data & AI, Redstone Realm, and Governance & Best Practices – while continuously refining our solution through your direct feedback – we believe CraftPortal represents the complete ACDC vision, and we thank the judges for challenging us, guiding us, and inspiring us to build something truly worthy of this win.

Thank you for ACDC 2026!

With love, team LogiQraft.

PS! We really wanted to share a PREMIERE of our final movie with you, before the official release so here you go https://www.youtube.com/watch?v=KV2p3FNTLNI

Event-Driven Autonomous Agent Solution

Posted on by

The challange described in our blogpost – Who is the King of Integrations? Or what? (Add link?)  was that excisting integration libriraies fto connect to Bambu lab local API provided very limited functionality and not fully optimized funcionality we could interacr with our 3D printer. 

Here is our second game plan using low code tools  where we tudned to RPA capabilities in Power Automate workflow. This is also an option since as Solution Providers Logiqraft wants to have multiple option available for our customers when they decide to use our app but migh have problems related to networking or other issues.

We combined Copilot Studio autonomous agent with Power Automate Desktop. When a user updates a recipe status to “Ready to Print” in the Model-Driven App, the autonomous agent detects the change in Dataverse, posts a notification to Teams, and triggers the RPA flow. The RPA then opens Bambu Lab Studio and clicks Print. The physical printer starts the job.

Going with the Flow: Wiring Steve to the World

Posted on by

Some recipes are simple. A user-friendly UI is enough: Steve publishes a request, Wandering Traders reply with recipes, deal done.

But some recipes are complex. Specs are unclear. Steve doesn’t know exactly what he needs. There’s back-and-forth: questions, clarifications, files, photos, technical drawings.

We need proper channels. Share specs. Exchange files. Chat in real time.

Discord would work in the gaming world. But we’re building on Microsoft cloud.

So we use Modern Workplace, AI WORKFORCE suite: Teams, SharePoint, and the whole M365 family.

The Challenge: Connecting SharePoint, Teams, and Dataverse

As experienced consultants, we know the options:

Option 1: Server-side sync Quick. Efficient. But locked – not flexible when you want to extend. And no Teams integration.

Option 2: Dynamics 365 Teams Integration The out-of-the-box “Collaborate” button. Sounds good, but: it creates a separate Team or channel for each record. For our solution, that means a new channel for every single Request. Hundreds of channels.

And it’s not automatic – users still need to click “Collaborate,” choose to create new or merge to existing. Manual steps. Extra friction. Our users aren’t ready for that level of complexity just yet!

Our Use Case

As customer-oriented Redstone Engineers, we know adoption is everything. We wanted:

  • Fully automated
  • Zero clicks from user
  • One Team, multiple channels (one per tender)
  • Documents synced to the right place

The Solution: Power Automate

We know how OOB sync works under the hood. There’s a Document Location entity – the infrastructure connecting SharePoint to Dataverse.

We also know that when you create a Teams channel, SharePoint auto-generates a document library for it.

So we wired it up ourselves.

When a Tender is created:

  1. Teams channel created under the main Tender Team
  2. SharePoint folder structure generated
  3. Document Location record created in Dataverse
  4. Everything linked. Automatically.

Fully customized. Total freedom. Zero lines of code pro code. (Shoutout to FetchXML Builder from XRM Toolbox – making us look like we know what we’re doing since day one.)

Categories: #Redstone Realm, #low-code

Who is the King of Integrations? Or what?

Posted on by

As you already knows, yesterday we released an article to demonstrate the ability interact with 3d printers, such as reading the temperature on turn on/off the light. In nice to have, but very limited functionality for out project. It was a challenge to grab camera stream and run the printing job using Local API…. 

After some nightly research, we found the solution. There is a addon for the Home Assistant which will allow us to perform any action with the 3d printer locally.  

 To make it work in tight deadlines, we decided to run the Home Assistant app on our laptop, using Hyper-V, and expose port securely via the Cloudflare tunnels which is also providing HTTPS certificates. 

We are claiming the following badges: 

  • #Nasty hackers,  
  • #Thieving Bastards: we are using Cloudflare, Open source  Home Assistant and Bambu lab HA integration addon. 

Categories:  

  • #Low code – for the integrations with Bambu lab local printer API without single line of the code 
  • #Governance & Best Practices – following best practices of exposing only secured services to the public internet 

Minecraft Dataflow – Recipe Import 

Posted on by

This document describes the dataflow used to import external Minecraft items into the application and map them to the Recipe table, enhancing the value of existing data that we have in the model driven app. The recipes are then used by our customer/user. 

1. Dataflow Creation 

A new dataflow is created using a blank query. The query connects to a public Minecraft API to retrieve item data in JSON format. 

2. Minecraft API Query 

The blank query is named “Get Items” and contains logic that calls the Minecraft API, converts the response into a table, and selects the required item columns. 

3. Dataflow Connection 

The connection is configured to allow the dataflow to access the Minecraft Items API. 

4. Execute the query 

Once the connection is established, the query is executed automatically to retrieve data from the Minecraft API. 

5. Table Mapping 

The output of the query is mapped to the desired Dataverse table (la_recipe). Each column from the API response is mapped to its corresponding column in the Recipe table. 

6. Dataflow Publish 

After mapping, the dataflow is published so it can be used for importing data. 

7. Running the Dataflow 

The dataflow can be scheduled or run manually. The first execution occurs automatically if it is set up as manual. The progress and status can be monitored. 

8. Check Results 

After the dataflow has run, the imported data can be verified in the model-driven app to confirm that Minecraft items are available in the Recipe table. 

Show and tell – CraftPortal Evolved: From Minecraft to Supply Chain

Posted on by

in our first post, we talked about the problem. Supply chains are slow. Parts ship across the world. Weeks pass. Carbon burns. Sometimes the manufacturer doesn’t even exist anymore.

We asked: what if supply chain worked like Minecraft?

Now let’s show you what we mean. (no, its not the same picture)

Think about how Steve plays Minecraft.

Steve needs a diamond sword. He doesn’t call a supplier in another country. He doesn’t wait for a ship. He finds the recipe, gathers materials, walks to his crafting table, and makes it. If he needs something far away, he uses a portal – instant.

Now think about CraftPortal.

A customer needs a part. Instead of ordering and waiting for shipping, they log into the Portal and post a request: “I need this part, these specs.”

IP Owners see the request. We call them Wandering Traders. They don’t ship physical parts – they sell recipes. Digital blueprints. They bid on the request.

Customer picks a recipe. Downloads it through the portal. Instant – like Steve stepping through a Nether portal.

Now the customer has two options:

Option 1: They have their own 3D printer – their Crafting Table. They print the part locally. Done in hours.

Option 2: They can’t print it themselves. They order from a Manufacturer – a Villager with better equipment. The Villager crafts it for them from a local facility.

Either way: recipe travels through the portal, part gets made locally.

No ships. No planes. No weeks. No carbon.

The Tech Behind It

The Portal is Power Pages – the marketplace. Recipes live in Dataverse. Copilot and AI Builder handle automation and intelligence. Azure IoT connects the Crafting Tables. Model Driven App runs the back office. Teams keeps everyone talking.

And LogiQraft? We’re the Redstone Engineers. We build the wiring that makes it all work.

Minecraft Procurement & Crafting Process 

Posted on by

This document explains the end-to-end process from the perspective of a player (Steve) using the Model-Driven App within the Minecraft-themed procurement and crafting system. 

1. Player Login (Steve) 

Steve is a player (user) who logs into the Model-Driven App. From here, Steve can manage Projects, Recipes, Crafting requests, and track all activities. 

2. Creating a Project 

Steve creates a new Project. A Project represents a request for a specific item or component that needs to be sourced or crafted. 

Within the Project, Steve specifies: 

  • Deadline (when bids should close) 
  • Budget (in Emeralds 🟩 / EM) 
  • Recipe or Component required 

3. Publishing the Project 

Once all Project details are complete, Steve publishes the Project, changing its status from Draft to Open. Publishing makes the Project visible to Vendors via the Power Page (Power Page will not be covered here). 

4. Vendors: Villagers & Wandering Traders 

Vendors are external parties who interact with the system via the Power Page. There are two types of Vendors: 

  • Villagers: Crafters and shippers who can manufacture (print) and deliver items. 
  • Wandering Traders: Providers of Recipes or Components, offering 3D-printable designs. 

5. Bids (Handled via Power Page) 

Wandering Traders can view published Projects on the Power Page and place Bids. A Bid includes the price for providing the requested Recipe or Component. 

Although Bids are created through the Power Page, all Bid records and statuses are visible to Steve in the Model-Driven App. 

6. Selecting a Winning Bid 

Once the deadline has passed, or earlier if Steve is satisfied, Steve selects a winning Bid. 

The selected Bid determines which Wandering Trader will provide the Recipe or Component. 

7. Contract Creation & Signing 

After a Bid is selected, a Contract is automatically created and sent to the winning Wandering Trader for signing. 

The Contract formalizes the agreement, including price, delivery expectations, and terms. 

8. Receiving the Recipe / Component 

Once the Contract is completed, Steve receives the Recipe or Component. At this point, Steve has two options: 

  • Print / craft the item themselves. 
  • Request a Villager to craft and ship the item. 

9. Creating a Crafting Record 

If Steve cannot or does not want to craft the item personally, they create a Crafting record. 

In the Crafting record, Steve specifies: 

  • The Recipe to be crafted 
  • The selected Villager 
  • Shipping details (not yet implemented) 

Villagers will charge an additional fee for crafting and shipping, which is tracked within the system. 

10. Visibility & Tracking 

Although Villagers and Wandering Traders primarily use the Power Page, all records, logs, and statuses are also visible to Steve in the Model-Driven App for full transparency. 

11. Recipes Management 

Recipes can be created in multiple ways: 

  • Automatically by selecting an item from the Minecraft API. 
  • Manually created by a player to define a custom Recipe. 

Recipes can be reused across Projects and Crafting requests. 

The Name column is implemented as a PCF control using Fluent UI React v9. When the magnifying glass is clicked, a modal window appears that calls the Minecraft API, allowing players to select a recipe and return its name, description, and icon. 

12. Summary 

This process creates a complete Minecraft-themed procurement and crafting flow. From Project creation, bidding, contracting, recipe sourcing, to final crafting and delivery. 

#low-code + pro code #category

LOW CODE: Power Pages Implementation PART 2

Posted on by

First part of this article you find here LOW CODE: Power Pages implementation | Arctic Cloud Developer Challenge Submissions

For back-office administration, we created an app called Owl Management:

This is a low-code, model-driven app where all functions for Wayfined Academy’s back office are handled, including student, faculty, application, inquiry, and survey management. And off course analytics to provide a helicopter view:

From the low-code perspective, we created a sitemap using both OOB sitemap and app editor.

We also highlighted how this was done previously with XRMToolBox’s Sitemap Editor which saved us, low code experts, from editing the sitemap directly in XML:

We paid tribute to a famous blog post that made waves in the community. Megan shared a clever hack on how to add some color to the system by using emojis, which really took the community by storm! Today, of course, we would prefer to implement this using JavaScript Web Resources attached to views, but we wanted to give a nod to this iconic hack! Here’s the link: Using Emojis in OptionSet Fields.


and the result;D

The app also includes Business Process Flows, Staging, Branching, and more—all done with low-code:

And the activities are assigned to the Student using Power automate (trigger on student request update/create

Student will see all the activities on the My Activities page in Power Pages in the List:

When the Survey is assigned to the Student – user navigates to the Survey tab and the first question appears on the screen:

LOW CODE: Power Pages implementation

Posted on by

We have built a portal for students using Power Pages.

We were utilising the best no-code features available.

On a landing page, we did a quick and easy set up of the header with a logo of our academy, added the links to the pages. 

The student first opens it and clicks a button “Find me a school” to start the process of finding a better school for them. The student is redirected to the Submit Request page:


The submit request page contains a form of the student that they should fill in:

On submit the student will be redirected to the My Requests page:


On the backend, the managers see the request:

And the activities are assigned to the Student using Power automate (trigger on student request update/create

Student will see all the activities on the My Activities page in Power Pages in the List:

When the Survey is assigned to the Student – user navigates to the Survey tab and the first question appears on the screen:

LOW CODE category and Crawler for social data

Posted on by

As a team, we have a primary goal: We help magic happen by utilizing modern AI approaches. 

We also understand that every student needs a mentor, but the number of available mentors is minimal today. Our idea is to introduce digital twins for available mentors, which would allow us to help a more significant number of students. To achieve that, we are using all available data about the mentors. But to keep it fresh and reliable, we must have the latest events in our OneLake. 

So, we implemented the LinkedIn profiles’ social crawlers to track all the mentors’ activities and events and suggest new potential mentors. 

We do that via the most modern and most straightforward way by utilizing the PowerAutomate Desktop: 

Then, the data will be collected and stored in an Excel spreadsheet, making it available for future processing with our Data Factory.  

The primary consumer of the data regarding upcoming events is the students, who use the complex search request to find the proper event by searching across different fields. Participation in community events potentially increases the chances of successful onboarding to the new school. 

Relevant search API functionality if covering 98% percent of the required functionality. Unfortunately, this API is unavailable on the Power Pages side. We implemented the Power Automate Flow from the portal, a wrapper around the original Dataverse API, to resolve that issue. 

On the portal side, we are using the Select2 component to implement autocomplete functionality.