Ryan: Welcome back to the deep dive. Today we’re really getting into something that I think frustrates a lot of people. Using modern ERP systems. Specifically for Microsoft Dynamics 365 Business Central users, we’re talking about that workflow gap. You’ve got this powerful system, bc, right? Handles tons of stuff, but there are always those little tasks, the specific things your business does, that just don’t quite fit the standard screens exactly.
Emma: Like maybe your delivery driver needs to snap a specific kind of photo for proof of delivery.
Ryan: Or the supervisor on the floor needs to log a really detailed safety check. Maybe something unique to your setup.
Emma: Or even just adding one mandatory field for quality control that the standard module somehow missed. It happens all the time.
Ryan: And what happens? You end up falling back on paper or spreadsheets, which is maybe slightly better, but still disconnected.
Emma: Right? Or worse, some clunky external app that doesn’t talk to PC at all.
Ryan: Yeah, creates silos.
Emma: It really does. It’s kind of the achilles heel of ERP, isn’t it? The system nails, say, 95% of your business processes perfectly. But that last 5%, the stuff that makes your operation unique, that often ends up being tracked manually somewhere else. And that fragmentation, well, it slows things down, introduces errors. It’s a mess.
Ryan: So, okay, our mission today isn’t just to complain about these gaps, tempting as that might be. Our mission is to look at this really powerful shift that’s happening. It’s allowing users, the actual BC users, to close those gaps themselves.
Emma: By building their own custom mobile applications.
Ryan: Exactly. And the kicker is, without needing to write a single line of code. No developers involved.
Emma: Precisely. We need to define that outdated model first. You know, the one where fixing a tiny workflow issue meant this huge, huge project.
Ryan: Oh, yeah. Big budgets, long waits.
Emma: Right? And then contrast that with the modern solution, which is really about empowerment. It’s about giving the super user, the person who actually knows the process, the power to fix it using visual tools. Configuration, not code.
Ryan: So the software stops being this rigid.
Emma: Thing you just used and becomes more like a platform you can actually shape to fit what you do.
Ryan: Okay, let’s really focus on the pain of that old system for a second, because I think everyone listening who’s dealt with customizations can relate. Let’s say you need one small change. Just one. You need the warehouse team to have to capture a lot number before they pick an Item for a specific order type. Simple requirement, right?
Emma: Seems simple, yeah.
Ryan: But traditionally, making that happen, that meant meetings with a developer, writing up specs, waiting maybe weeks or months for them.
Emma: To get to it, then testing, deployment.
Ryan: And writing a pretty big check at the end of it all for one small change. It always felt disproportionate. Why should tiny workflow tweaks require these massive, expensive projects?
Emma: Well, they shouldn’t. And that’s exactly why this technological shift we’re seeing is so important, so critical. The key is embedding the customization tool right where the data lives. So we’re talking about tools like Warehouse Insight and specifically its built in app Designer.
Ryan: App Designer?
Emma: Yeah. This tool basically bypasses all that coding complexity. It talks directly to the business central data structure. Your tables, your fields. And it puts the power to design the application, the mobile screen, directly into the hands of the people who really get the workflow.
Ryan: The managers on the shop floor, maybe the warehouse supervisors.
Emma: Exactly. The super users, the people who live that process every day.
Ryan: Now, I have to admit, hearing App Designer still makes the IT governance part of my brain a little nervous.
Emma: Right.
Ryan: I picture, you know, command lines and code editors.
Emma: Right, I did that.
Ryan: But you’re saying. And the sources really emphasize this, it’s purely configuration, no code.
Emma: It is entirely configuration based. Seriously, think of it less like programming and more like. Well, maybe like designing a flowchart or using a visual builder.
Ryan: Okay.
Emma: You’re literally dragging functional mobile controls, like a button, a text box, a camera trigger, onto a design canvas. It’s almost like arranging objects in PowerPoint or something similar.
Ryan: All right, let’s slow down there and get really specific for the listener. Imagine I’m that floor manager. I need a simple screen. Maybe just to confirm if a forklift passed its daily safety check. Yes or no. What specific functions can I actually configure using this drag and drop approach?
Emma: Okay, good question. You’re building screens, mobile pages that handle core mobile functions. And it goes way beyond just showing data. Obviously. You can configure it to demand barcode scanning. That’s table stakes for warehouse stuff.
Ryan: Sure.
Emma: But you can also set up controls to capture photos, high resolution photos.
Ryan: Oh, okay. Like for approve of delivery or damages.
Emma: Exactly. Or recording electronic signatures directly on the device screen.
Ryan: Nice.
Emma: You can build step by step guided inspection checklists. You know, walk the user through. Check this. Yes. No, check that. Enter value.
Ryan: Like a wizard.
Emma: Kind of, yeah. And critically, you can capture location data, so timestamps, GPS coordinates pulled right from the mobile device itself.
Ryan: Okay. That’s quite a range of capabilities just through configuration. Let’s make it even more concrete. Use the simplest possible example, the classic hello world of programming. Okay, forget the forklift check for a minute. If I just wanted an app that when I open it, it displays the.
Emma: Text hello world, you mentioned concepts like events, interactions and variables. For a user who knows their BC data but isn’t a coder, what do those actually mean? In practice?
Ryan: That’s a great way to frame it, because these aren’t programming concepts in this context. They’re really workflow concepts. Let’s stick with your hello world idea.
Emma: Okay.
Ryan: An event is just what starts the action, the trigger.
Emma: Yeah.
Ryan: So for hello world, the event might be simply the form opens. That’s it.
Emma: All right. Simple enough. The trigger. So the form opens. That’s the event. Then the system needs to do something.
Ryan: Exactly. And that something is the interaction. The interaction is the specific command you want to happen. So if the event is the form opens, the interaction would be something like display message.
Emma: Okay. Event form opens, interaction, Display message. Makes sense. And finally, the variable is just the data itself, the content. In this case, the variable would hold the text string hello world.
Ryan: Ah, I see.
Emma: So the whole configuration is basically just linking those three things visually. When the event form opens, happens, then perform the interaction display message using the content from this variable, hello world, you connect the dots in the designer. No code written at all.
Ryan: That framing triggers actions, data, not abstract code terms. It makes a huge difference. Okay, so that helps understand the basic building blocks. That gets us past the theoretical hello world and into the real world. What happens when we start combining these, when we ramp up the complexity a bit?
Emma: Well, the best proof of concept, honestly, is to look at some pretty sophisticated add ons that have already been built entirely using this method.
Ryan: Add ons built with the app designer.
Emma: Yes. Take the proof of delivery solution pod, they often call it. That entire system which supports field drivers capturing delivery details was built entirely within the app designer.
Ryan: Wait, hang on. That. That kind of changes the whole definition of an add on, doesn’t it? It’s built with configuration. It sounds more like an organizational capability than, you know, a separate software package written in al code that you buy in.
Emma: And really insightful way to put it. Precisely. This policy solution configured visually captures complex stuff. The customer’s signature on the screen, photos of the delivered goods, maybe showing damage if something went wrong in transit.
Ryan: Okay.
Emma: The exact timestamp of the delivery, the driver’s GPS location when they completed it. All this very specific structured data captured.
Ryan: On a Mobile device out in the field.
Emma: Captured on the mobile. Yes, and this is crucial because the app designer is directly connected to the underlying business central database.
Ryan: Ah, the real time aspect.
Emma: Exactly. All that data feeds straight back into B.C. in real time. So the sales order status might get updated instantly. Or the shipment record shows delivered with the signature attached without anyone doing any manual upload or middleware sync.
Ryan: Wow. Okay, that Polari example is pretty compelling. So if that’s possible, what else are people actually building with this? What are users configuring for themselves?
Emma: The scope is getting pretty massive. Honestly, it’s moving way beyond just tweaking existing screens. We know from the sources users are creating very specific safety inspection checklists for.
Ryan: Their assembly lines tailored to their exact process.
Emma: Yep, Equipment maintenance logs that when you complete them, instantly link that log back to the specific fixed asset record in bc.
Ryan: Okay, that’s powerful. Connecting physical actions to financial records.
Emma: Driver workflows are huge, obviously beyond just Polari. And the list keeps growing. There are already user created, let’s call them mini apps or add ons for things like managing fixed asset counts out on the floor, creating new license plates directly from the handheld.
Ryan: Oh, that’s handy.
Emma: Customized overpicking workflows so handling exceptions the way they need to. Even apps to enforce specific expiry date entry rules during picking or put away.
Ryan: So it sounds like if you can clearly define the sequence of steps, the workflow you need on the mobile device.
Emma: You can pretty much build the app for it using these configuration tools. The main limitation really becomes just your imagination about which manual or clunky process you want to digitize next.
Ryan: Okay, this naturally brings us to the strategic side of things. We’ve talked a lot about empowering the super user, the person on the floor.
Emma: Right.
Ryan: But what about the, you know, the strategic decision makers, the IT department? If we’re letting potentially lots of people build these mini apps, who owns the maintenance? Doesn’t this just shift the bottleneck from the IT developers who are scarce to maybe super users who have their actual day jobs to do?
Emma: That’s a really critical point about governance and it’s actually a key benefit of doing it this way.
Ryan: How so?
Emma: Because the control and standardization comes through the configuration framework itself. Unlike shadow it, you know, where people might use random spreadsheet apps or weird third party tools.
Ryan: Yeah, the stuff it hates finding out about later.
Emma: Exactly. Every app built here using the app Designer exists within the managed environment of Warehouse Insight. It interacts directly and only with approved business central tables and logic that you permit IT’S sort of self documenting by its nature because the configuration is the documentation.
Ryan: Okay, so it’s controlled empowerment, not a free for all.
Emma: Precisely. And that leads directly into the big organizational benefits. There are several key takeaways here for the listener. First, and maybe most obviously, faster innovation.
Ryan: Right. We talked about the three month wait for a small fix before.
Emma: Yeah. With App Designer, you can prototype, test and deploy what they call a minimum viable app. You know, the simplest version that works often in days, not months. You can try out new workflows, get immediate feedback from the users on the.
Ryan: Floor, and tweak it right away and.
Emma: Roll out the changes instantly. It drastically reduces the cost and time of just trying things.
Ryan: So if an app idea doesn’t quite work out, you haven’t sunk six weeks of expensive developer time into it. You just adjust the configuration or maybe scrap it and try something else.
Emma: Which ties directly into the second big benefit, lower costs. You completely skip that traditional development queue for these kinds of high impact, but maybe small scope.
Ryan: With workflow adjustments, you’re basically converting a capital expense or a major project expense.
Emma: Into an operational efficiency task. A super user might spend an afternoon configuring a solution that saves hours every week, instead of you spending thousands on external development.
Ryan: Okay, faster, cheaper, makes sense. But I imagine the IT team, their biggest concern is often data integrity and consistency. When you have dozens of different paper forms or spreadsheets floating around, your data’s.
Emma: A mess, it’s inconsistent, it’s hard to aggregate, it’s often useless for real analysis.
Ryan: Absolutely. Which brings us to the third strategic game, Consistency. By building these custom mobile apps inside the Warehouse Insight and Business Central framework, you ensure all that critical operational data, whether it’s quality checks, maintenance logs, delivery confirmations, whatever stays inside Business Central.
Emma: So you eliminate those data silos we talked about earlier. Exactly. Everything lives in one place, using the same data structures, reportable through the same tools.
Ryan: And that really speaks to the true power shift here. Right, which sounds like your fourth point. Empowerment.
Emma: It really is giving the operational team, the people who actually feel the friction points every single day, the control to design their own solutions means the solutions are much more likely to actually feel fit the reality of the work.
Ryan: So you get better adoption problems, better.
Emma: Adoption, higher quality data entry, simply because the people using the tool had a hand in building it. It creates a sense of ownership, not.
Ryan: Just compliance, ownership, not just usage. I like that.
Emma: And finally, there’s scalability. Because you’re designing these apps using a centralized designer tool. You build it once and you can instantly Deploy it everywhere, across multiple warehouses, maybe different sites, globally, even different subsidiary companies, assuming they’re all running on a compatible BC and warehous Insight setup. Build once, deploy many.
Ryan: That really seems to be the ultimate takeaway then, doesn’t it? Business central with tools like this is evolving. It’s moving from being just a necessary system that you use, maybe grudgingly sometimes. Yeah. To becoming more of a living, breathing extension of your specific unique business processes. And it’s being configured and customized by the very people who know those processes best.
Emma: It is genuinely transformative for the organizations that embrace it. So just to quickly recap for everyone listening, the combination of Warehouse Insight and its built in App Designer lets you go way beyond basic screen tweaks. You can build really robust data capturing mobile experiences, handling things like photos, signatures, GPS coordinates. And you do it all through drag and drop configuration, no coding needed, bypassing.
Ryan: That whole traditional development cycle.
Emma: Completely bypassing it, allowing you to focus directly on solving your unique operations problems, often in near real time.
Ryan: So what’s the advice for someone listening who thinks, okay, this sounds interesting, maybe we could use this?
Emma: My strongest advice is don’t wait. Don’t wait for it or an external consultant to maybe someday get around to fixing that annoying process constraint you deal with every day, right? If you have Warehouse Insight with App Designer available, or if you’re considering it, start simple. Pick one high friction process, maybe digitizing a paper checklist, or enforcing one specific data capture step that keeps getting missed.
Ryan: Just get a quick win.
Emma: Exactly. Build your own hello world, whatever that looks like for your operation. That simple, tangible win will instantly demonstrate the power of this visual configuration approach far better than any presentation could.
Ryan: It really does change the conversation internally, doesn’t it? From oh we can’t do that, the system doesn’t support it to okay, how quickly can we configure an app for that and get it deployed?
Emma: Totally different mindset.
Ryan: So if, as you say, basically every process gap can potentially be filled with a simple user configured app, maybe built in just hours or days, here’s a provocative thought for you, the listener, to mull over. What legacy manual process, what paper form, what spreadsheet workaround is currently slowing down your team the most? Think about it. Because that process, whatever just popped into your head, that’s probably your next mobile application project.
Emma: Good question to end on.
Ryan: Thank you for joining us for this deep dive. We’ll catch you next time. It.
