If you follow us on social media, hopefully you’ve seen that we at Engineered Code shared some exciting news this week. We announced ecLearn, a learning management system (LMS) built on top of Microsoft Dataverse. In this blog post I’m going to give you a bit of a glimpse into the ecLearn journey.
Microsoft’s Power Platform is constantly growing and evolving. As much as everyone (especially Microsoft) wishes that all parts of the Power Platform worked seamlessly together, the reality is that many parts of the Power Platform existed long before Microsoft started using the word Power to group these technologies together. However, I believe that advancements in virtual tables, specifically for Power Pages, emphasizes the fact that Dataverse should be at the core of any Power Platform implementation.
The price point for Power Pages has long been a tricky discussion point. The pricing model has changed a few times of the years, and organizations can feel frustrated if they are on the wrong end of who ends up paying less and more when the model changes. In this blog post, I’ll review the history of the pricing for the product, and provide my opinion on whether I think the cost is justified by the value.
The growth of Power Pages has been an amazing story. Since being acquired by Microsoft in 2015, the product has gone from a niche add-on for Dynamics 365 Customer Engagement to a full-fledged product in the Power Platform. The visibility that comes with getting equal billing to other Power Platform products like Power BI, Power Apps, and Power Automate means that new people are discovering Power Pages all of the time. However, as with any software product, Power Pages isn’t always a fit, even if your project fall under the category of low code web application development platforms. In this post, I will share what I look for when trying to determine if Power Pages is a fit for a given project.
The fact that Power Apps Portals uses Bootstrap as its CSS framework means we have a lot of tools as our disposal (yes, I know we’d all love it if we could use a newer version of Bootstrap, or even pick whatever framework we wanted, but that is a topic for another day). Unfortunately, some of the Bootstrap components require specific markup that we can’t achieve with configuration alone. In this post I’ll cover how we can use JavaScript to change the markup on either Basic Forms or Advanced Forms so that we can leverage the Input Group functionality (in case you missed the memo, Basic Forms is the new name for Entity Forms, and Advanced Forms is the new name for Web Forms).
One of the subjects I seem to be dealing a lot with recently is invitation codes – so much so that this was the featured topic for this month’s Portals Community Call. During that call I promised to share a small bit of CSS that would hide the “I have an existing account” checkbox on the Redeem Invitation page, so I’ll do that in this post, as well as give a bit of background as to what the checkbox is used for, and why it most cases you probably don’t need it.
While Microsoft continues to invest heavily in the Portals Studio, which provides a new What You See Is What You Get (WYSIWYG) editing experience for Power Apps Portals, there are still many good reasons to use the Legacy Front-side Editor. In this post I’ll describe how you can add additional styling options to the rich text editors to allow content authors to create consistent pages.
It’s been too long since I’ve posted! With all of the virtual conferences taking place in 2020, I couldn’t find the time to get any blog posts done. But I plan to change that in 2021. First off, I want to share a solution for when you want to use the Condition type of Web Form Steps, but your condition is more complicated than just checking if a regular field equals a specific value.
The Web Forms functionality lets you build complex multi-page, multi-entity wizard-style forms on your Power Apps Portals. And while there are a ton of options, it’s not uncommon to run into situations where you can’t do everything you want with configuration, so you might need to resort to a bit of JavaScript (and maybe even Liquid). One of those situations is if you want the source entity for the next step in your Web Form to be a record related to the entity of the current step.
The power of Entity Forms in Power Apps Portals is that they mirror much of the functionality available in model-driven apps (and Dynamics 365). While the parity isn’t 100%, one advanced feature that Entity Forms does support is Related Records Filtering on lookups, where the available options in the lookup are filtered by some other data that has already been selected. However, in certain cases, this functionality doesn’t offer exact parity out-of-the-box – one of those cases is when you are creating a new record via a subgrid, and you’re expecting that the parent record is used in the filtering of the lookup.
