S1E23 - Solving Podio Gaps 5: "GlobiFlow Race Conditions, Long Flows, & Look-ups"

Speaker 1: 0:03

Music Intro

Gil Roberts: 0:10

Welcome to the Podio Solutions Podcast season one, episode 23 I'm Gill Roberts and with me today is our lead developer here at Brick Bridge consulting, Alex Shull. Hello and our principal consultant, Jared Duker. Good afternoon. This podcast is about the design and development on the Citrix podio platform. You can find that at Podio, p o d I o.com. We use this podcast to discuss our own experiences with the podio platform as well as other interesting topics from the podio developers community. If you're a designer or developer working at an agency, small business or enterprise, you should immediately hit that subscribe button. If you have already, Thank you so much for your support. Lastly, before we dive into today's topic, if you have a topic, issues, solution, problem, or anything else you'd like to discuss with us, we want to know about it, hit us up on our Facebook, linkedin, Twitter, or send us an email or podio message at podcast@brickbridgeconsulting.com. Today's topic is solving podio gaps. Number five. We're going back to the back on gaps, uh, these two weeks. Uh, so we're going to dive into some more of the troubles that our fellow podio users are experiencing and see if we can offer any kind of helpful advice as we do on this part of the series. Um, and maybe give some alternatives or suggestions, uh, to be able to solve the gap. Uh, we've, we've seen so far we've been batting pretty high percentage of doing. I know we tend to say, you know, a lot of custom stuff, but a lot of these, uh, feature requests really is custom work and it's hard. So let's, go ahead and grab a good one right off the top. Uh, Alex, this will be near and dear to your heart. Uh, we had Matthew, uh, B y r n e bearn, burn? Sorry, I always mispronounce names, but Matthew, thank you so much. Uh, for your question here. Again, we're pulling these off of help.podio.com. Uh, this one was put down on June 25th, 2019. Uh, so very close to the show here, less than a month ago. Globiflow race conditions, long flows and sub routines. Uh, this is a little bit of a long one, but I think I want to, oh, we want to dive into this. So, uh, Matt here says, hi everyone. I have created some really long complex flows in globi flow and have run into a maximum globi flow size limit. I've also run into problems with race conditions in which I try to perform some action and it's not completed by the time I want you to perform the next uh, another action or the next action. I have searched for how to create multiple flows on Linkedin, but I have not found anything that seems to cover what I want to do. In essence, I would like to have a sub routine flows that I can call from main flows. My worry is that if I mainly trigger a first sub routine flow from a main and then manually trigger a second sub sub routine from the main, the second will start running before the first one is complete. I have used the wait action but it is a bit overkill. 30 seconds. He says in parentheses and you can also use only one per flow. I'm not aware of any way to create a loop to act as a delay other than pulling a bunch of records and looping on them. I'm sure podio doesn't like just looping calls. Anyone provide guidance on how to have a first flow wait for a second, flow to complete. Thanks Matt.

Alex Shull: 3:50

Well, great question Matt. Um, yeah, there's a lot to unpack here. Let's see, that's, this is a very recent one. So hopefully you're listening, um, to, uh, to this. Um, let, let's, let's start with you. You, you, you talk about race conditions, long flows and sub routines. So, um, three separate subjects we can address. The race conditions obviously means that you have two things happening in parallel. You want one to finish first, but you don't have control over it. And so sometimes you, the wrong one finishes first and it creates problems. That's basically what you're talking about. Um, the, the problem is that, um, if you're experiencing that with globi flow, you might be experiencing it more fundamentally with podio because the event structure of Podio is, um, very asynchronous. It has to be. And so something we've dealt with a lot is item change, item update. You know when an item gets updated, an event goes out and you're your globi flow fires off. So if you're listening for that and um, someone goes and updates field one, podio picks that up right away as far as the event. They updated field 2, podio picks it up separately; they fire an event. You updated field three, Podio picks up that separately and fires the event. If you have a long running flow, then you just fired it off three times unless you put some kind of check in there. Now there's, I don't know to what extent podio does the d bounce logic, which means that they'll wait a little while before they let the event fire again. They'll let a few more updates percolate in because they haven't even run the first one. That's de bounce. I don't think they do it at all. I think as soon as an update goes in, boom, you can count on that event firing

Gil Roberts: 5:48

My experience is that yeah, you can rapid fire on update hooks.

Alex Shull: 5:52

We know it can happen. And we built our own layer in our sassafras event engine that gives you the option of locking out a function to say, I heard that that an event fired again, but I'm already running this function so I'm just going to complete the function. And it's a design choice. You have to design the application to respond to events that way and you, you might need some more complicated de balance logic where you say, I've heard that in the next hour, I'm going to let any other update come in and then I'm going to fire this flow again. Yeah, you kind of set a mark or you can have, um, you know what we do as the function locker. That's a, that's an event. Um, that's uh, a feature of the Saasafras event engine though. So it's a custom development within, yeah, go ahead.

Jarett Duker: 6:46

It took you weeks to actually iron out all the, all the little bugs. But it's, it's a very effective way of handling the multi event, uh, issue that we ran into with a sequence sensitive flows. Right.

Alex Shull: 6:59

And now it's just a feature of our engine. Just like there are features in the globi flow engine, there are features that are available to us cause we use that engine internally. On the globi flow side though, the way to achieve something similar, um, is to, you can in theory have an administrative app that sits kind of off to the side that tracks the execution of things where when an event comes in, you set a flag on an item there to say, I'm going to run the event. You actually run the event out of the secondary app. And that way if another event comes in, you can go look up the record and the flag has already set else, you know, in a different way. That means don't run the event. And so you, it's, it's a, it's a layer on top that some people are not comfortable getting into and they really just want to use custom.

Gil Roberts: 7:49

Okay. So let me like put that back out a little bit. Plainer English. In other words, what you're saying is, uh, a way to, to maybe run your own d bounce so to speak, is to open up a new workspace, put an app in there when something runs over in a different app, in a different workspace that it creates an item in that app, this administration app-- looks up or creates-- right and then it, um, then it actually executes over and ad environment. Yeah, turns results back over to the original where where the user's at

Alex Shull: 8:22

and you can have an, an item relationship to where the item that initially fires the event has the related item to that to say a flow execution item where you track it, track characteristics of that flow. You can get much fancier then and it's still within Globi flow so you can, as long as your fundamental actions that you're taking, you know, aren't, don't require anything beyond globi flow that can give you. Now, I'm not saying that I recommend this, that's why we built sassafras so we don't have to do that every time. But

Jarett Duker: 8:55

that also solves the race, the race scenario issue. Yeah. Yeah. That's what I'm thinking right now though is do you need to have a one to one parody of control items to actual data items or could you get by with a single control item that is referenced via a lookup.

Alex Shull: 9:12

There are different configurations. Once you understand that general pattern, there are all sorts of ways you can spin it up for the exact scenario.

Jarett Duker: 9:19

Be Very explicit what we're talking about right now because I think this is some gold that some people might really be able to benefit from. We are talking about a simply separate app that carries a relationship field to your database app. It has category fields that can be manipulated based on flows in the first app. That's right. That then can be read and the event triggers off of that control app can then trigger other flows thereby ensuring your race conditions are met

Alex Shull: 9:47

or other conditions. It's almost like a shadow app that sits behind your data app and it, it has metadata and you can use that metadata to change the way that globi flow operates.

Jarett Duker: 10:04

Without a bunch of comments or changes on the item that the person's using that they don't care about, probably shouldn't see. And with hook events, you can trigger actual cascades of events in correct sequence by listening to the up the update hooks on that shadow app.

Alex Shull: 10:19

And we did a lot of this in the earlier in the earlier versions of our complicated systems. And what I would say is that if you go in this direction, just be consistent about the way you name flows. Because if you go into globi flow and you see a bunch of stuff in there, you can trace it all down and there, there are people out there writing software to help you manage those things. Yeah, go that that can make it easier, but at the same time just consistency and name is going to get you a long way. You use the pattern consistently, it'll make your life easier, it'll make other developers life easier. So that that's the, the the, the one, just one piece of this. So the next piece was consistent, but it was definitely hacky. Yeah. Well, we'll get into some either more hacky things. This is entertaining. Yeah. I like to go down memory lane. So the second part of it is talking about long flows and you know, long flows. He hit The limit. Yeah. I didn't know there was a limit in boxes. Yeah. Yeah. So the, the thing about long flows is um, you basically have to go into custom code or you have to chain them where one flow calls a the next calls the next calls the next, and you can do that where if it's so long the last thing just triggers the next one and you can chain a bunch of stuff. Uh, I do not recommend, I don't recommend it. I really don't. Um, you're getting into an area where a little investment in some custom code, is gonna get you really far and your skills are probably much closer than you realize to be able to write that code yourself. Now I may be pushing people, I, to me, it's easy. So you can chain them along if you must use globi flow and you're requiring yourself to stay within those boundaries. Yes. Long flow trigger the next one. Now the problem is passing data because if you have some big loop, you lose that loop once you go into the next flow.

Gil Roberts: 12:23

You're almost put back into that control or shadow app again for these long flows are disjointed now cause you're breaking them up. Right. To drop data off and pick it back up.

Alex Shull: 12:35

Yeah, I would have all sorts of questions as to why is your flow that long. I mean realistically and this Jared you know, normally goes into an operation. He breaks down their systems, he breaks down their operations and he takes the pieces of logic into the smallest chunks possible. Cause you don't want to have long, long chunks of logic if you don't have to.

Jarett Duker: 12:58

We've seen so much instability on the server side. And if data integrity is essential to you and it is to everywhere I've ever been, those flows represent just massive leaks in data integrity because it's so easy for it to just misfire or skip a section

Alex Shull: 13:15

and just... Yeah, where did it error out, what do you have to roll back now? You know? And it's also the way that you maintain a complex system is to maintain it as an interaction of simpler systems. You want to have the simplest chunks to maintain which are interacting in a complex way. You can't reduce the complexity, fundamental complexity, but each one of those pieces should be as simple as possible. Yeah.

Jarett Duker: 13:41

The, the nastiest thing I've ever dealt with was uh, uh, a reports flow that needed to pull arrays of data from seven different apps, organize it into a table and then display it, spit out a pdf report that was massive. Um, I'm struggling to think of logically what you would need to do, uh, that would require that um, long flow in terms of data manipulation.

Alex Shull: 14:05

I would say the only, the main thing that I think could be expected is if you're looping through making an API call or something like that. Cause that lead bi call can certainly extend, you know, out a slow response, you know, all those kinds of things. But look, globi flow isn't built for all the error handling that is required to do that in a consistent way. So again, you can have an administrative app sitting off to the side that captures there's, that gives you that. Guess what? We've built all that. I've been there and so we've, we've built that. Yeah, go ahead.

Jarett Duker: 14:44

I'm gonna list. One other thing which is the most ignored box in globiflow but uh, might represent the middle ground between spinning up their own AWS instance and globiflow, which is the post get. Yeah. That allows you to run a smaller custom code blocks as a part of a globi flow environment. Don't know many people who extensively use the post get box, but it can be very powerful

Alex Shull: 15:07

once you're there. And once you go into Procfu you open up a world ofabilities that again, they're not actually more complicated than globi flows. So it's these very small steps forward, but the possibilities just expand in front of you. So yes, because you can break up those flows, dump variables off, and then come get them later on in the flow without having to do

Gil Roberts: 15:31

a bunch of things inside of the flow to keep juggling.

Alex Shull: 15:35

But how you design your application is critical because you might just need an intermediate app where the first step of this long run in your flow, long running flow is just populating data into this app that you can just trash at the end of it. When you're done with it, just throw it away. Just throw it away. You don't need to keep it around. Or podio lets you keep it for free. Keep it around if you want to.

Jarett Duker: 15:57

Get really creative even by running error checks, by checking conditions on the completion criteria of your audit app, and then running the individual pieces that you need to run. Again based on the failure conditions of, of your logic, you can get a lot done by creating those audit--

Alex Shull: 16:18

--and, and you're can apply them same kind of control, logical structure to the process.

Jarett Duker: 16:22

As wella s a place that can receive output errors. Um, and create a logging for you if it gets it gets poor man's logging.

Alex Shull: 16:29

Yeah. So, so there you go. We encourage people to think about, um, you know, custom code in a lot of instances if you really do have long money needs with complex API interactions, administrative app capabilities really expand, you know, what you can do. Procfu really expands what you can do in that same kind of globei flow field that same footprint. So the last piece that goes with this is sub routines, um, to this was, this is the one that we're still discussing, but the subroutines is of special interest to me because I did work out another way, um, prior to the Sassafras event and just being able to support the more complicated code scenarios where the, I got around to some of the retry conditions that you might experience with API calls and the, the retry conditions are important because sometimes you don't get a good response. You don't want to have to monitor that, fire that off again, you want to just to retry. So the retry conditions were maintained by instead of how you can't have a flow call itself, but you can have a flow call, a different flow that calls it back. Right? And so by having that little handoff loop, it's a hackaround, sorry I gave away the secret Andreas. But um, you gotta be, you can get into conditions where it's an infinite loop. So don't do that. You have to have some kind of check in there to where Andreas doesn't have to go kill your, your, your, your whoever's, you know, running the, the back end there. So, but that way you can do a little check, you have to check passes, you run your logic. If the check doesn't pass, you wait 30 seconds and call a flow. That flow does the same thing. It just calls back to the first one when it's done. There you go, there's your retry logic right there. Now, now the, the subroutine part of that is really logically the same thing because you are concerned about having a system that can call subroutine and guarantee that they're done. Okay. So take the idea I just described. And instead of having one flow call another think of having a master flow that keeps track of a step number and either the step number is good and therefore it can call the flow that is that step. And when that flow completes it calls back to the first one and all you have to do is hand off, you know, keep track of whether the flow completed or not. And so that way you can build those delays and retries in and it will keep trying to do step one over and over and over again until step one is complete. And then we'll move on to step two and it will keep trying to do step two over and over again until it's ready to move on to step three. And again, you can get into an infinite loop. You don't want to do that. But if you put in the correct logic for checking, reading some podio item to see whether the step is completed or not, and if all else fails, you know, erroring out your globi flow. Just some food for thought.

Gil Roberts: 19:46

Yeah. These, these are ways, obviously the best way to kind of kill all this or is to go with a custom flow engine. Just in general. I mean obviously we have ours, there's other ones available. Um, you could make your own with the, these flow engines take care of a lot of this issue, these problems cause you can, that, you know, the world's your oyster when you, when you're sitting there in front of the console and being able to, to actually program this out, PHP, Java, c sharp, whatever you're using. Um, you just, you just have, you don't have the little blocks on the flip side of that, you also have to know how to code it. Yeah. Or payfor somebody that does know how to code it out.

Alex Shull: 20:27

You get that full flow control. Um, it's powerful, but it isn't wiziwig anymore and that's, you know, so you don't get the ease of use. Um, but again, you know what I just flushed out. If you're comfortable doing that, then it'll work. It'll work. And your next step is custom code anyway because you're just dealing with something that's probably more complicated than coding.

Gil Roberts: 20:53

Maybe try it that way and you made sure that the business process is validated and what you're doing and then you can move that easily off onto a custom use. Use globiflow to prototype.

Alex Shull: 21:04

Yeah. Yeah. I was going to say, a lot of what we did when we first converted to an application in Sassafras, we took big complicated flows that worked at steps like this and were you know, handled different conditions and we reduced the number of flows. Maybe you know there was 10% of what it started off.

Gil Roberts: 21:26

Yeah, something like that. It really went down significantly. There's just less because cause function it's more compact, right? Yeah. The functions can handle more right there rather than having to worry about the globi flows and having to do all this stuff,

Alex Shull: 21:39

but you're able to read it directly from the flows is the is the nice thing. It's like you don't, you did. We didn't have to reinvent the logic. The logic was written in globiflow. All we did is translate it to a different language. Yeah. So the investment in globiflow was never lost.

Gil Roberts: 21:57

Uh, there was one little sub part of this and then we'll leave this one alone, which is where he talks about the wait action 30 seconds on my, um, I'm not aware of another way to create a loop. I don't use all that.

Alex Shull: 22:10

Well, that's what I was just saying. You could do. You can do the little call each other loops. Yup.

Gil Roberts: 22:15

Would you still have 30 seconds or are you-- seconds plus 30 seconds plus 30 seconds. Are you saying it's overkill? Can we get less than that?

Jarett Duker: 22:23

Can't do. But the solution that we've already talked about of using, uh, controls you really, uh, I, I've stopped using the wait all together. I haven't, I haven't put that block in one of my flows in a year. Now it's unnecessary. There's much more reactive ways to do things by calling manual flows. And I'm just sitting here right now thinking about, I've always used a kind of control card that contained category fields and moved key manipulate category fields around to control complex actions. Now I'm imagining a workspace that contains multiple audit log apps and the actual creation of a referenced item in that app is the category field. It serves the same function. So it's a binary choice. The item exists or it does not exist. And based on search events run inside of Podio, you can create dynamic logic that way because again, I didn't exist or it does not exist and there's no, there's not a lot of costs in podio for creating and deleting items. So you can just populate and depopulate these apps to create a control panel. Um, just based on reference Ids that you generate arbitrarily during the process, delete them out after flow runs immediately, you can save them for or put them on a timer. I don't have to, unless you're, you know, you're creating hundreds of thousands of them, but I've always used a card that had con had a category fields, but I'm now thinking of another way of just using an app that just creates a, a single field item.

Alex Shull: 23:52

You know, it's also interesting because if you think about dynamically creating an item to support an interaction for a podio user, one of the things about an item is that that unique item can be updated just with a very simple, you know, single category interaction and drive all sorts of custom logic. Yeah.

Jarett Duker: 24:15

Now you have a second set of create and update events that you can be using to manipulate your flows.

Alex Shull: 24:22

Yeah, that's a really, that's a really compelling thought because that's an application design concern that you just raised. You what, what you're talking about to me is fascinating because it's a podio pattern and it's very unique to podio because it's this administrative control layer that is woven and directly to the fabric of podio. But it lets you use the, again, the fundamental structure of Podio to um, really extend that, that control it. But it's a pattern again. So the pattern is that you have an app application data in a certain workspace and dynamically you're going to generate items in another workspace that captures key elements out of the, the items in the, in the first workspace. We'll walk, walk through it again.

Speaker 5: 25:17

Well, what I would do is I would, I would use the external id of an item of the, I'm going to call it my control item, which is what I'm wanting to manipulate. And then in another workspace I could have an entire array of apps and just create an item and populate a single number field, which is easily indexed by Podio with that external id of the, of my control item. Then as a search event, I can check does this one and or if and not this exist yes. Proceed with this flow and not run this, run this function to fix my data.

Alex Shull: 25:55

I see. Yeah. So you, so you could have, um, item life cycle control that's configurable in this separate workspace. Effectively you're talking about being able to have, um, a, a very much more complicated workflow around those data items

Jarett Duker: 26:13

with a simple, with a simple yes or no, uh, a positive or null response. Does an item exist from the standpoint globi flows? Yes. Filter checking in globiflow? Yes. Well, instead of using, um, information on an item using an item itself, the existence or nonexistence of an item. But again,

Alex Shull: 26:35

the context is the globi flow, then you can add those checks very quickly. So it's rapid prototyping of pretty, you know,

Speaker 5: 26:44

complicated structures that answer a lot of concerns you might have. And then you can start using those classic logic operators and if or nor xor, you know, stuff that most people have seen if they've ever worked in logic.

Alex Shull: 26:58

That's great. I hope people understand what, what Jared is saying there because it's, um, it's a, it's a, it's a great design pattern and it actually, um, has many ways that that same pattern can be applied.

Jarett Duker: 27:10

We're just pushing the box out a little further of what you can do without any API integrations for podio

Alex Shull: 27:17

you're capturing and maintaining the very advanced application state that is beyond the basic level of how you lay out your data in podio. You're, you're actually letting yourself then maintain another layer layer of data about the work that's being done with those items as well. So, great. Those are, those are great. Yeah.

Speaker 5: 27:37

And, and with indexing, you don't have to have relationship fields. You don't have to clutter up your relationships.

Alex Shull: 27:41

Yeah, yeah, exactly. And this is something that supports filtering. It supports the, those quick filter checks in Globi flow. It's fast too

Jarett Duker: 27:51

You can even use the tag system.

Alex Shull: 27:54

You do a, um, if you do a multi item, get out of podio using the filterable fields, it's fast. It's built for that out of the box. So yeah, those related items, you know, that's great ideas.

Gil Roberts: 28:06

I think we've, we've covered that one pretty well where there was a lot in that. Yeah. And what he's got there, of course a podio sport suggested to reach out to the globiflow team on that. I, I,

Jarett Duker: 28:18

Or you could just listen to our podcast. We sit around all day and think about ways to extend what you can't, what the horizon is.

Gil Roberts: 28:28

We are always looking for people to send us their problems. Uh, we were pretty good at solving them. All right, let's do one more. I'm going to do the lookup across apps. Uh, one, um, this came from, it looks like, uh, Eby says, hey guys, with such a powerful tool, I'm sure this is possible. What I'm confused on how I want to Abi autopopulate details of an order when a single field is updated, parentheses, the name of the product ordered and I'm going to, we'll come back to that. Effectively. That means I want to look up the individual components required to make that product and then populate the request in the app. So far, even using workflow features doesn't seem to let me reference the components of the product as saved in the other app. Can anyone help? Now when we first read this or like, well you probably just need to go for globi flow, maybe do some globi flow work there, but then we caught name of the product ordered single field and I'm wondering if it's a text field that they're updating and some of the problems that could be generated trying to generate some dynamic action off of that.

Jarett Duker: 29:38

There's two things. It sounds like they're just using workflows. Yeah. Um, and I'm going to tell you get globi flow. Yeah. Move to globi flow. You can, there's a several ways that you can do this. However, if you want to remain completely just out of the pop box podio without any additions, you can do this through a calculation field. You can reference other app items just like you would a globi flow with a calculation. Now your glow, your javascript skills need to be a, I don't know, at least a yellow belt or higher. Um, because if it is a text field, you will have to parse that text field and explode it, remove any special characters and then bring it into a readable string and hopefully people didn't put in Typos. Right? Cause you're just done if they put in typo's. They're not using a text field because that just sounds like a horrible idea.

Alex Shull: 30:27

How do you populate the request in the app based using without using globiflow? Just using the workflows. Cause it also...

Speaker 5: 30:35

You don't need to use workflows. Uh, the calculation fields can look up other information and populate information. Well, she actually, well no, I think what she wants to do is write the name of a product or let's, let's, let's assume she's using a calculator, category field. She wants to click a product. There is a dictionary of related items to each of these products. So let's say she's building a toaster and they put toaster in, she needs a chassis, some springs, these parts. She wants to pull all those together and just list what needs to be ordered in order. Toaster. I'm good. I'm good. I'm going off the cuff.

Alex Shull: 31:16

Um, maybe. Okay. My, I read it differently so I'm going to address it from the standpoint of how, how I interpreted this. Um, I think that um, there is a single field that is going to be updated, which is the name of the product ordered, but someone's going to create an item. They're going to type in the name of the product ordered. And I think that the fundamental, um, issue is you need to have a product catalog where you look up the names. You don't type in the names. You need to have a lookup from a related item. Yeah. That's what you need to do. You're, I think you're using it wrong. I'm not, I'm not positive. But from your description, if you're not using a referenced item, you're using it wrong. Once you have a referenced item and once your order references a product in your new product catalog, then you can populate whatever you need in the request, the components of their product as saved in the other app.

Speaker 5: 32:14

I'm going to go one step further though because I think what she's saying is, let's assume she has a product catalog. Related to that, product catalog is a larger catalog of parts that are the component parts of each individual one, so they have a large catalog of products and a much larger catalog of parts and then into the product you want to get through the department. So she is going to a new product order comes in, you list the product, you, she's wanting to look through that product catalog and list out the component parts in a discreet way. Yeah. So there's a look through uh, multiple relationships. It's a view you view, it would be a view, but I also with a calculation field, you could look through and pull down all of that and just write it out and just get it.

Alex Shull: 33:01

You can write it out, but depending on what you want to do with it of you, if you build a view, then your view of the product

Jarett Duker: 33:08

could include the product parts and then you would link to that product or globi flow could just spit out an excel html table or an excel sheet. Once you go to globi flow all of this changes. But yeah, she needs to have a product catalog and then a component parts catalog. It's like they're assembling custom, I don't know. But you know, most products have component parts. Yeah. She's wanting to know all the component parts she needs to order probably across multiple orders. I need, I need 246 widgets a and 300 widgets B to make these 200 products.

Alex Shull: 33:44

Yeah, I think you're right. And, and I, you know, it's multiple orders come in.

Speaker 5: 33:51

.

Alex Shull: 33:51

Well they might be the same parts across different products. So you want to total parts, you know, some... Yeah.

Speaker 5: 33:57

For the month I need to order so many of x, Y and Z in order to combine them together into these orders.

Alex Shull: 34:04

Yeah, there you go. Yeah, I think that hopefully that gives you enough direction. If you're listening in, you can get that Evy and uh, solve your problem cause uh, definitely podio, globiflow. They'll take care of you. We're, we're always here

Gil Roberts: 34:20

to bail you out if you have any problems as well. Um, alright so that wraps it for gaps. Episode number five, all of our links to the ones that we pulled a for this show will be inside of the show, description, um, and uh, that way you can take a look and possibly add your comments right there on the form, um, as well. Well, thank you guys so much once again for another great gaps episode. If, uh, we're always looking for new gaps to solve. Uh, we go through the user forms, um, and the help forms, but you can also contact us as well with your own issues, problems, or, or maybe even innovative solutions that you've, you've solved some of your own problems for. We'd like to hear about those as well. You can hit us up on our Facebook, linkedin, Twitter, or send us an email or podio message to podcast@ brickbridgeconsulting.com that does it for episode 23, and we'll be back with you next week with some more great value. So thanks for listening. If you haven't already, please subscribe and have a great rest of your day. Thank you. Thank you.

Speaker 6: 35:37

Music Outro.