Tag Archives: ACDC Craftsman

Owl Express – Application Lifecycle Magic

Posted on by

Howl to do ALM.

OwlExpress365 – ALM Manifest 

Development and Deployment Approach  

We do have some rules defined how development should happen and be planned in general, all around ALM (Application Lifecycle Management). There can be some differences for each product in terms of their complexity and circumstances. 

Technical and development-specific rules: 

  1. Solution and Components should all have the same publisher.  
    There should be only one Publisher for all Products that should be used across all components and solutions. 
     
  1. The technology approach and implementation are crucial for the scalability of the product and should be chosen wisely at the beginning of the project. 
    Deprecated functionality needs to be replaced as soon as possible and not even considered in the first place.  
     
  1. Every solution must be available as unmanaged in an own environment which is part of the tenant. Each solution should only have changed and newly developed components and no dependencies on non-product-related solutions.  
    The Environment must contain access for global Administrators and the Development Team.  
  1. Solution components must follow internal specific naming conventions. (e.g., icons: hel_*name of the icon’_icon.svg) 
  1. Solutions contain a changelog providing the latest changes and updates made to the solution  
  1. The solution is connected to a git repository. Changes are tracked automatically, while commits happen after crucial changes and before updates.  
    All commits must contain a speaking comment to provide context of recent changes.  

Deployment 

Our target is to continuously improve our deployment process with fewer manual steps. We distinguish today in three different processes of deployment: 

  • Code Component / Custom Control Deployment 
  • Solution Deployment  
  • Release Distribution 

Each of these processes comes with a different scope, restrictions, and requirements. But all of them should be based on the ALM (Application Lifecycle Management) Approach.  

Code Component / Custom Control Deployment 
Accessed by: Developers 
Purpose: Deploy changes to Dev
Functionality: Build the desired branch version of the code repository (e.g., Custom Control, JavaScript, Plugin, Application) and update the target dev environment with the selected version. 

Solution Deployment 
Accessed by: Maker, Developers, Product Owners 
Purpose: Build and deploy the desired Solution version to UAT And Production Environments 
Handled by: Power Platform Pipelines  
Functionality: Check-in changes in the Repository, Export the latest version from DEV Environment, Quality Check on Export (Solution Checker) , Build Solution via Build Environment (unmanaged), potential Automated Testing, Export Solution as managed, potential Quality Checks, Store Artifact as managed in Repository, Deploy managed Solution to QA / Test Environment  

(Example pot. Solution Deployment)  

Release Deployment 
Accessed by: Product Owner 
Purpose: Build and store release-candidate Solution version  
Handled by: Build and Power Platform Pipelines  
Functionality: Build Solution via Build Environment (unmanaged) / direct by code stored in repository, Automated Testing, Export Solution as managed, Quality Checks, Store Artifact as managed in Repository 
Long-Term: Build AppSource Update Package and deploy 

Automated deploying of solutions minimizes the risk of human errors during that precise process. Especially with a larger team and multiple versions and branches, we want to be more than sure that all the functionality, features, and fixes we brought into the product are part of the solution we deploy.  
It opens accessibility as well for Testers and QA’s who do not need to have a full understanding of the manual deploying process.  

Product Artifact 

The final artifact we produce at the end of each development and deployment cycle is not only the technical product but our idea of how to leverage all the different and innovative aspects of the Power Platform for our customers and their end-users.  
 

OwlExpress365 – Tech Stack & Environments 

Power Platform 
Environments 

  • HOST
    Owl Express Host Environment: https://owlhost.crm.dynamics.com/ 
  • DEV 
    Owl Express Dev: https://owlexpressdev.crm.dynamics.com/ 
  • UAT 
    Owl Express UAT: https://owlexpressuat.crm.dynamics.com/

All Environments are organized in the same Environment Group “Owl Express.” They are also managed and organized with Security Groups to organize access.  

With a security group and role-specific permissions as security roles, we have full control about  the access to each environment and don’t interfer with other environments on the tenant.   

Solution Concept 

We currently drive a single-solution approach for customizations and development, that includes all custom components and changes we perform on top of Dynamics and Power Platform. AI and Copilot development is not included here, there is a separate solution to enable deployments and development in parallel.  

All changes are tracked with the Git integration to Azure DevOps and pushed to the repository with major changes and deployments.  

https://dev.azure.com/owl-express/_git/Owl%20Express

Changes are deployed to separate Dev branch. Via Pull Request and additional review by at least one other person than the author, changes can be merged into the main branch for productive usage.  

Deployment  

All dev solutions are transported automatically from the dev environment as managed to the UAT and Production environment. With the Power Platform Pipelines, we can trigger a UAT only deployment or a full deployment, which covers UAT and Production.  

The pipeline is triggered from the Dev Environment. During the validation and publishing, we generate a new artifact in the Host environment and increase the version number. The final deployment happens through SPN, which requires additional approval (posting to Teams) for the production environment.  

The version number is set up to meet the following criteria: 

MajorVersion.MinorVersion.Date.NumberOfDeployments 

Release Notes are AI-generated while we maintain custom release note via Configuration Page, this provide functional context and technical details.

Further Solution Distribution 

The Power Platform Catalog is an additional source to distribute our solutions within the tenant. With each crucial change, the developers are publishing a new update to the catalog. The request will be verified and approved if all criteria are met.  

Afterwards the new update is available in the catalog for makers and low code developers.  

Dependent solution deployment 

OwlExpress uses some third-party solutions. These will be deployed as managed solutions to the different environments. The deployment happens via Azure DevOps Pipelines: 

After discussing internally between Azure DevOps Pipelines and GitHub Actions, we decided to stay centralized in Azure DevOps.  

The following third-party solutions are used: 

  • dhino 
    Purpose: Authentication of external users against Dataverse Data (OwlExpress app) 
  • Solutions 
    – dhino_API_Core_1_0_0_23_managed.zip 
    – dhino_Authenticate_1_0_0_27_managed.zip 
    – dhino_Fetch_Core_1_0_0_58_managed.zip 
    – dhino_Forms_Core_1_0_0_2_managed.zip 
  • PCF Tag Control 
    Purpose: Add Characteristics to a Student via a tag control on the form directly  

     
  • Solutions 
    – OPC.PowerApps.PCFControls.zip 
  • Resco PCF Control: File Uploader 
    Purpose: Used to attach Files to an Student Application  

  • Solutions
    – pcf-file-uploader-1.0.0.0.zip 

PCF Development 

PCFs are being created using a Test-Driven Development approach. We are also using cdsproj based solutions to simplify the build and deployment to the target environments. The cdsproj enables us to create the solution zip file easily and import that using the “pac cli” or the Power Platform Tools from Azure DevOps. 

The full source code is also stored in the used Azure DevOps Repo, to aim for a full centralized development surronding  

Frontend / Static Web Apps 

The frontend app “Owlexpress.app” is developed as a custom static web app using HTML / CSS / JSX. It is checked in to a GitHub repository with automated deployment triggers for the connected Netlify sites. Netlify was chosen because it offers the best support for static web apps when using them in a hybrid mode with server-side rendering which we need for the authentication part. 

Tech Stack 

  • Astro Framework 
    Base Framework for static web apps 
  • TailwindCSS 
    CSS compiler 
  • Daisy UI 
    TailwindCSS component library 
  • Dhino  
    ntegration with Dataverse with authenticated external users 

Environments 

  • DEV 
    Locally on machine 

Deployments 

Deployments are triggered by pull-requests on the main branch and are executed within the Netlify deployment system. This was chosen because Netlify supports all the server-side rendering capabilities needed for the authentication part of the static web app. All secrets are set up as environment variables to keep them outside the repository. 

Fabric / Power BI 

We maintain alignment with all Dataverse environments by having the following Power BI workspaces configured: 

All development activities are carried out within the DEV workspace. We then leverage Pipelines in Fabric to deploy changes into each downstream environment. This allows us granular control when deploying components and to view potential “diffs” between environments: 

AI and Copilot  

Copilot related components are structured in a separate solution to the already existing customizations. Components used across multiple agents are organized in solution-aware component collections.  

Because creating a new agent generates a various number of components, we decided to split. Also to potentially deliver our solutions without AI for different Regions. Europe, looking at you.  

As all components are part of the Power Platform solution that is on the Dev / Test and Production structure of the Power Platform we can use existing Power Platform Eco-System including Pipelines for the deployment and also publish the AI components to the Power Platform Catalog.  

Virtual potion ingredients: XR in PCF components

Posted on by

We already have access to MR (aka. Magic Reality) components in Canvas Apps. Implementation is straight forward, but as expected they come with a limited set of features. The components are based on Babylon.js, and make for a quick and easy way to place and view a 3D model in an augmented reality context.

For our solution, we wanted the user to also be able to interact with the virtual objects in front of them, which is not OOB features, so by expressing our power user love, we decided to explore the possibilities around custom XR enabled PCF components.

Being ACDC craftsmen, knowing the potential issues of going too far down the wrong path, we decided to do some proof of concepts, creating custom PCF components with third party XR libraries, acting like proper thieving bastards on the way.

First off, we had a look at AR.js, which is built on ARToolkit, a relatively old library. This library could provide us with wide device support, which really didn’t have that much value, considering the component would be running inside the Power Apps mobile app. We would also be forced to use either image target or marker tracking, with no modern AR spatial tracking.

Looking closer at the OOB components, we tried to find a way to leverage the OOB Babylon.js logic, hopefully being able to hook into the React Native part of the implementation, which would give great benefits in terms of access to device specific XR features (ARCore for Android and ARKit for iOS). We did, however, decide to leave this path, and focus elsewhere.

Crafting Excellence: Weasley Twins’ Development Best Practices

Posted on by

Environments

Our solution utilizes three distinct environments within Power Platform: Development, Testing, and Production. The Development environment is where initial coding and development take place, supported by robust version control to ensure code integrity and traceability. The Testing environment is used for rigorous testing to ensure code quality and expected functionality. Finally, the Production environment hosts the live code that is actively used by students.

Power Platform Pipelines

To streamline the movement of code between these environments (DEV – TEST – PROD), we have implemented Power Platform Pipelines. This ensures a smooth and efficient transition of code through each stage, maintaining consistency and reducing the risk of errors. Automation tools and scripts are used to facilitate this process, enhancing efficiency and minimizing manual intervention.

Environment variables

We leverage environment variables to manage our SharePoint sites and lists across different environments. This approach provides us with precise control and flexibility, ensuring that each environment operates with the correct configurations. Environment variables support dynamic configuration, allowing for easy updates and changes without altering the codebase.

Connectors

Our solution employs a smart naming standard for connectors. This naming convention simplifies the process of tracking and reusing the appropriate connectors, enhancing maintainability and clarity. Comprehensive documentation of the naming standards and usage guidelines ensures consistency and ease of understanding for new team members.

Service Account

We have established a dedicated service account for the twins to use with connectors, enhancing security by isolating permissions and reducing credential exposure risks. It simplifies auditing and ensures consistent configuration across environments. Adhering to the principle of least privilege, it grants only necessary permissions, providing clear accountability and preventing identity spoofing. Monitoring tools track the service account’s activities to ensure compliance with security policies.

ALM CATEGORY: With the ALM Lumos spell, we illuminate a path to error-free, efficient lifecycle management. 

Posted on by

“Building this solution has been a journey of passion and precision, where every element has been designed with purpose and care. We’re excited to showcase our work as a testament to quality and innovation in pursuit of the ACDC Craftsman badge.

We have three environments, DEV, TEST, and PROD, with different approval flows. 

So, the production environment can be deployed only after the release manager has approved it. 

We implemented an Export pipeline to simplify the contribution process.  

Users can decide which solution to export and place in the GIT to track the change’s history. 

For the functional consultants, we implemented the following flow: 

The export procedure includes exporting the managed and unmanaged solution packages. All changes from the selected solution will be included in the PR, and the Solution Checker will start the validation process. A clean report from the Solution Checker is a prerequisite for the next step of the PR review, which requires the real human review step. 

In the case of pro code customization, each component type has its steps for the PR validation, such as: 

  • Run build to produce the artifacts: 
  • Run unit test 
  • Scan the code base with SonarQube (Quality Gate) 

The Import pipeline will deploy the package with a specific type based on the environment, so deployment to PROD will always include only the managed version of the packages. 

The import pipeline also includes extra steps to activate the flows after deployment, including calling the custom Power Shell script to activate the disabled flows in specific solutions. 

We also use a custom version that reflects the build date and the build number at the end: 2025.01.25.13; from our previous experience, it looks more meaningful to the users. 

Branching strategy: 

We are using a trunk-based branching strategy. Short-lived branches contain as small changes as possible to make the review and validation process simple. 

Crafting Perfection: PowerPotters’ Quest for the ACDC Craftsman Badge

Posted on by

Greetings, wizarding developers and tech sorcerers! ✨

At Team PowerPotters, we take pride in our meticulous craftsmanship. From modular code design to robust CI/CD pipelines and seamless hardware integration, every aspect of our solution reflects a dedication to excellence. Today, we unveil the full spectrum of our development practices as we humbly submit our case for the ACDC Craftsman badge.

🪄 The Cornerstones of Craftsmanship

1. Modular Python Code for Seamless Integration

Our potion production system relies on a trio of well-structured Python scripts, each dedicated to a specific task:

  • sensor_script.py: Captures real-time data from ultrasonic sensors, seamlessly integrating with our IoT platform.
  • voice_script.py: Powers AI-driven voice recognition using the OpenAI Whisper API, enabling potion masters to command the system verbally.
  • integration_script.py: Acts as the conductor, tying sensor data and voice commands into cohesive workflows with Power Automate.

This modular structure ensures clarity, maintainability, and scalability, allowing individual components to be refined or extended independently.

Best Practices in Python Development:

  • Error Handling and Logging:
    Detailed try...except blocks ensure stability by gracefully handling errors, while comprehensive logging captures critical information for troubleshooting.
  • Mocking for Testability:
    Using a GPIO mock module, we simulate sensor behavior during testing, enabling rapid iteration without needing access to physical hardware.

🧙‍♂️ 2. Automating the Magic with GitHub Actions

To ensure our hardware remains ready for action, we created a GitHub Actions workflow that automates ESP32 firmware updates.

ESP32 Firmware Deployment Workflow:

  • Triggering the Workflow: Commits pushed to the main branch automatically initiate the firmware update process.
  • Code Checkout: The workflow uses the actions/checkout@v3 step to pull the latest code onto the runner.
  • Installing Dependencies: The esptool Python package is installed to enable communication with the ESP32.
  • Flashing the ESP32: The firmware is flashed using a shell command:
on:
  push:
    branches:
      - main
 
jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
 
      - name: Install Python dependencies
        run: python -m pip install esptool
 
      - name: Flash ESP32
        run: |
          python -m esptool --chip esp32 --port COM3 --baud 115200 write_flash -z 0x1000 .pio/build/esp32dev/firmware.bin

This process ensures fast, accurate, and automated firmware updates, reducing the risk of errors and saving time.

Why This Workflow Matters:

  • Automation: Eliminates manual steps, ensuring reliable and repeatable firmware updates.
  • Hardware Integration: Bridges the gap between software and IoT devices using a self-hosted runner for direct ESP32 access.
  • Scalability: Adaptable for multiple ESP32 units, making it a powerful tool for future growth.

✨ 3. CI/CD Pipelines: From Development to Deployment

Our CI/CD pipelines exemplify best practices in automation, ensuring smooth transitions from development to production:

  • Pre-Build Pipeline:
    A smart script starts the build box and waits for the service to become available before initiating the express build, which performs a simplified build without syncing.
  • Full Build Pipeline:
    If the express build succeeds, the full build pipeline is triggered. Success activates a webhook to:
    • Notify a Teams channel about the new release.
    • Trigger the upload of the package to the target environment.
    • Automatically deploy the package, ensuring rapid access to new features.

This pipeline streamlines the entire development lifecycle, ensuring efficiency and reliability at every step.

🧙‍♂️ 4. ALM Magic: Consistency in Customizations

Our Application Lifecycle Management (ALM) practices ensure clarity and structure across all customizations:

  • Naming Standards: We prefix all artifacts with Ad (Application Development) to maintain consistency. Examples:
    • AdCustGroup_Frm_Extension: Form extension for CustGroup.
    • AdCustGroup_Frm_dsCustGroup_fldGroupId_Extension: Field extension for CustGroup data source.

These conventions create an organized and easily navigable codebase, critical for large-scale projects.

🔮 Why We Deserve the ACDC Craftsman Badge

Our development practices embody the principles of the ACDC Craftsman badge:

  1. Modular, Maintainable Code: Python scripts are well-structured and adhere to best practices, ensuring long-term scalability and clarity.
  2. Automation Excellence: CI/CD pipelines and GitHub Actions workflows eliminate manual steps, streamline deployment, and reduce errors.
  3. Consistency and Standards: Rigorous ALM practices, including naming conventions and structured customization, reflect our commitment to professionalism.

🐍 Crafting a Legacy of Excellence

From clean code to seamless deployment workflows, we’ve poured our hearts into creating a solution that reflects true craftsmanship. With every detail carefully considered, we humbly submit our case for the ACDC Craftsman badge.

Follow our journey as we continue to innovate and enchant ACDC 2025: acdc.blog/category/cepheo25.

#ACDC2025 #ACDCCraftsman #PowerPotters #AutomationMagic #CI/CDPipelines

No room for code with low ambition!

Posted on by

Does the code contain lines with low ambition? No worries, we’ll catch those nasty lines in a PR from a feature-branch into the main-branch, with a proper peer review process.

Commits on the main-branch will trigger a GitHub Actions workflow, using GitHub Secrets to retrieve tokens used in the build-process; and automagically deploying the finished build to our Azure Static Web App.

Brewing Badge-Winning Elixirs with Pro-Code Potions and Beyond!

Posted on by

PowerPotters of Cepheo: Brewing Badge-Winning Elixirs with Pro-Code Potions and Beyond!”

Greetings, magical tech community! 🧙‍♂️✨ Team PowerPotters of Cepheo is thrilled to unveil our progress in automating elixir production for the ACDC 2025 hackathon. Our solution blends the powers of pro-code Python and low-code Power Platform to craft a system that’s both functional and badge-worthy. Today, we’ll reveal how we’re targeting the Pro-Code Potions category as well as these coveted badges:

  • Right Now
  • ACDC Craftsman
  • Thieving Bastards
  • Power User Love

Let’s dive into the details of how our Python-powered magic aligns with these badge aspirations!

1. Claiming the “Right Now” Badge: Python – The Heart of Our Brew

The “Right Now” badge rewards smart, clean, and efficient code that elevates solutions beyond the realm of low-code alone. For us, Python isn’t just an enhancement—it’s the engine of our magical elixir automation.

Python Scripts: Unlocking Advanced Functionality

Our Python scripts (sensor_script.py, voice_script.py, integration_script.py) are designed for tasks that Power Platform cannot handle natively:

  • Direct Hardware Interaction: Using RPi.GPIO, our sensor_script.py captures real-time data from the potion cauldron’s liquid level sensor. Power Platform simply cannot replicate this hardware integration.
  • AI-Powered Voice Recognition: Our voice_script.py leverages the OpenAI Whisper API for advanced speech-to-text processing, turning verbal commands into actionable automation triggers.
  • Intelligent Orchestration: The integration_script.py ties everything together—sensor readings, voice commands, and workflows via Power Automate.

With these examples, we demonstrate how Python serves as the lifeblood of our system, embodying the essence of “Right Now.”

2. The “ACDC Craftsman” Badge: Best Practices in Code

The “ACDC Craftsman” badge celebrates development and deployment excellence. Our commitment to best practices is reflected in every line of Python code we write.

Highlights of Craftsmanship:

  • Modular Structure: Each script (sensor_script.py, voice_script.py, etc.) has a single responsibility, ensuring clarity and maintainability.
  • Error Handling and Logging: Robust try...except blocks and detailed logging ensure stability and traceability
  • Mocking for Testability: The Mock folder includes a GPIO.py mock module, allowing us to test sensor logic without a physical Raspberry Pi. This approach accelerates development while maintaining code quality.

By embracing modularity, testability, and robust error handling, we ensure our code stands as a shining example of “ACDC Craftsman” principles.

3. The “Thieving Bastards” Badge: Leveraging External Tools and APIs

The “Thieving Bastards” badge rewards the clever use of third-party tools to amplify solutions. Here’s how we “borrowed” brilliance:

  • Open-Source Libraries:
    • RPi.GPIO and requests for hardware and API interaction.
    • sounddevice and scipy for audio recording and processing.
    • python-dotenv for secure environment variable management.
  • OpenAI Whisper API: This external AI service powers our voice recognition functionality, enabling seamless integration of advanced speech-to-text capabilities without reinventing the wheel.

We’ve strategically combined these tools to accelerate development and expand functionality, earning our place as “Thieving Bastards” in the best sense!

4. The “Power User Love” Badge: Pro-Code and Low-Code Unite

The “Power User Love” badge highlights the magic that happens when pro-code customization enhances low-code platforms. Our project is a perfect example:

  • Power Platform for Low-Code Power: Power Automate orchestrates workflows, while Power BI visualizes potion progress.
  • Python for Pro-Code Power: Python bridges the physical and digital realms, enabling sensor integration and AI-driven voice commands.

Together, these platforms create a seamless, intelligent, and user-friendly potion production system.

Conclusion: Badge-Winning Elixir Automation!

With our meticulously crafted Python pro-code and Power Platform low-code synergy, we’re confident our solution is a contender for:

  • Right Now
  • ACDC Craftsman
  • Thieving Bastards
  • Power User Love

PowerPotters of Cepheo are proud to combine technical excellence with magical creativity. We look forward to seeing the results and continuing to share our journey. Stay tuned, fellow wizards!

#ACDC2025 #PowerPotters #ProCodePotions #BadgeReady

Pipelines ALM – ACDC Craftsman

Posted on by

The ALM method of the Power Potters guild 🪄

Behold, the enchanted method of Application Lifecycle Management (ALM), where Power Platform Pipelines act as the Floo Network of solutions, transporting them safely from the cobblestone streets of Development to the bustling halls of Test and the grand castle of Production. Alas, our quest for a fourth environment—the illustrious Pipeline Host Environment—was thwarted by the restrictions of our trial license, which only permits the conjuring of three realms. As a result, we have cast a clever spell to install the pipeline application directly within the Development realm.

In the Development realm, solutions are left unmanaged, much like a young wizard’s first spell. By the time they graduate to Test and Production, they transform into managed solutions—properly polished and fit for their duties in the wizarding world.

With the ancient power of the run history scrolls, we shall keep an eye on the timeline of events, tracking mishaps and ensuring that the pipeline’s magic flows seamlessly. This vigilance allows for swift, safe development that races faster than a Firebolt broomstick

Realm Details

Realm NameTypeRegionLanguageCurrency
Dev – Power PottersTrialEUEnglish (US)EUR
Test – Power PottersTrialEUEnglish (US)EUR
Prod – Power PottersTrialEUEnglish (US)EUR
Pipeline Host RealmTrialEUEnglish (US)EUR

All realms are cloaked in the protective spells of “Managed” type and are set within the European Union’s borders. They share a common tongue (English, US) and currency (EUR), creating a unified magical system that prevents dependency conflicts, as if warding off a rogue boggart.

Let the Power Potters harness this method to charm their way to flawless, fast-paced development! 🧙‍♂️

The pipeline:

Naming conventions

WhatConventionExample
ColumnsPascal casepp_PowerPotters
SolutionsCapital letter for each word, short and descriptive namePower Potter Potion Solution
Forms
Views

Adding copilot to agent and moving across environments

Of course, because we developed the datamodel in DEV, we could also easily develop and train the Copilot Agent in DEV and move it to production using solutions and Power Platform Pipelines, as well as the AI Models, and the Power Pages site

Entra ID Security Groups

We use Entra ID / Azure AD Security groups to control who has access to the different environments.

The security group is linked to the environment.

A security team is linked to the security group in Entra ID, where security roles are assigned.

True ACDC

Posted on by

Development is nothing if your not in control. We are of course using seperate environments, so that we are totally in control of development, testing and our players in production.

Pipelines using the Power Platform Builder Tools is the Key here. The Pipeline exports our solution from the Development Environment, Imports it into our UAT (User Acceptance) Environment, before an approval step decides if the solution is finally deployed to the Production Enviroment.

Total control – total awesomeness!

The images below shows the solution in production before a change and after a change. We decided to use the NPC “Butler” as a story teller through the game. So when you complete a room and go back to the Main Map – the Butler now provides you with some context and information thats important for your progress in the game.

Thanks for easy deployment!

Final Stretch: Unlocking Advanced Badges on the Last Day of Development

Posted on by

As the ACDC Hackathon draws to its climax, our team’s dedication and innovative spirit have led us to target three advanced badges, each reflecting our commitment to solving complex problems with cutting-edge technology and best practices.

Crawler: Revolutionizing Assistance with Copilot Studio

In our quest for the “Crawler” badge, we’ve integrated Copilot Studio into our Power Page site, embedding a Copilot bot designed to aid users when they’re stuck on a course level. This ingenious feature utilizes a cloud flow triggered by the user’s input, leveraging the Dataverse action “Search Rows (Preview)” to find and return answers for the specified course level. This not only enhances user experience but also showcases our innovative use of search to solve a real-world business problem.

Client Side Salsa: Ensuring Smooth Performance with Modern Frameworks

Our pursuit of the “Client Side Salsa” badge highlights our application’s fluidity, achieved by running entirely within the client’s browser without becoming a cumbersome monolith. By crafting a PCF control for our interactive course game using TypeScript and React, we ensure our setup’s compatibility across a wide range of browsers. This approach underlines our strategic use of modern front-end frameworks to deliver a seamless and responsive user interface.

ACDC Craftsman: Demonstrating Development and Deployment Excellence

The “ACDC Craftsman” badge is a testament to our adherence to development and deployment best practices. We’ve established three environments (dev, UAT, & prod), focusing our component development within the dev environment. Our deployment strategy is streamlined through Power Platform ALM pipelines, incorporating a pre-deployment approval step via Teams. This allows for meticulous control over deployment timing and participants. Moreover, our use of Azure DevOps Repositories for the PCF control exemplifies our commitment to source control and project management excellence.

As we conclude this hackathon journey, these badges represent more than just our technical achievements; they signify our team’s holistic approach to innovation, user engagement, and operational efficiency. Our efforts to blend advanced technological solutions with practical application and meticulous project management illustrate the essence of true ACDC craftsmanship, setting a high bar for what can be accomplished in such a collaborative and competitive environment.