Citrix Developer Solutions Podcast

S1E6 - Solving Podio Gaps 1: "Series Intro & Google Calendar 2-Way Sync"

February 18, 2019 Brick Bridge Consulting Season 1 Episode 6
Citrix Developer Solutions Podcast
S1E6 - Solving Podio Gaps 1: "Series Intro & Google Calendar 2-Way Sync"
Chapters
Citrix Developer Solutions Podcast
S1E6 - Solving Podio Gaps 1: "Series Intro & Google Calendar 2-Way Sync"
Feb 18, 2019 Season 1 Episode 6
Brick Bridge Consulting

Podcast Outline – Season 1 – Episode 6 – Solving Podio Gaps #1

Discussion Outline:

  1. Introduction – Welcome to the Series
  2. Topic: "Solving Podio Gaps" -- a new series on our Podcast
  3. 1st Discussion: What this series is about.
  4. Hot Topic: Extending Podio Platform
  5. 2nd Discussion: Example Gap -- 2-way Sync with Google Calendar
    1. Defined Business Problem
    2. Explore Technical Limitations
    3. Outline of Potential Solutions
  6. Deep Dive: Theoretical workout of the solution on the Podio API
  7. Up Next: 
  8. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  9. Outro: SUBSCRIBE and Thank you.

Links:

https://help.podio.com/hc/en-us/community/posts/200519848-Two-way-sync-with-Google-Apps

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (https://www.buymeacoffee.com/brickbridge)

Show Notes Transcript

Podcast Outline – Season 1 – Episode 6 – Solving Podio Gaps #1

Discussion Outline:

  1. Introduction – Welcome to the Series
  2. Topic: "Solving Podio Gaps" -- a new series on our Podcast
  3. 1st Discussion: What this series is about.
  4. Hot Topic: Extending Podio Platform
  5. 2nd Discussion: Example Gap -- 2-way Sync with Google Calendar
    1. Defined Business Problem
    2. Explore Technical Limitations
    3. Outline of Potential Solutions
  6. Deep Dive: Theoretical workout of the solution on the Podio API
  7. Up Next: 
  8. Audience Engagement: Solving Podio Gaps – Podio Developers and Power users – Submit your gaps!
  9. Outro: SUBSCRIBE and Thank you.

Links:

https://help.podio.com/hc/en-us/community/posts/200519848-Two-way-sync-with-Google-Apps

Follow us on social media (@PodcastPodio) to stay up to date on all Podio Podcast news.

Support the show (https://www.buymeacoffee.com/brickbridge)

Gil Roberts:

I'm Gil Roberts with me today is our lead developer, Alex Shull.

Alex Shull:

Hello

Gil Roberts:

And our principal consultant, Jared Duker.

Jared Duker:

Good Afternoon.

Gil Roberts:

This podcast is about the design and development on the Citrix podio platform at podio.com podio. We use this podcast to discuss our own experiences with podio as well as interesting topics from the podio developer community, your podio designer, developer working at an agency, small business or enterprise, and 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 haven't topic, issue, solution, problem, or gap you would like us to discuss their solve, we want to know about it. So hit us up on Facebook, linkedin, and Twitter, or send us an email or podio message to podcast at brick bridge, consulting.com. B R I C K, B R, I D G E consulting.com. Today's topic is our first , uh, episode inside of a series here called, so solving podio gaps. Uh , this is going to be a ongoing series, a new series on our podcast where we're going to break down some of the issues that we find in the userforms, uh , ones that have been submitted by you as we've been asking for them across the episodes. Uh, we'd found one today that we'll go over. Uh , that's been outstanding for about six years. There's been very, there's been some progress, but a very little actual progress into a final solution. Uh , so we'll discuss that. Uh , but our first discussion is we're going to talk about what the series is about , uh , and we're going to look at how we can extend the podio platform , uh , to maybe help fill some of these gaps. So , um, I'll give you a quick hint on the format and then we'll dive right in. Uh , so what we'll do in future episodes, we'll be solving two gaps instead of one. This episode is the first , uh, so we'll talk about what the series about, what's all one gap as an example, a next episode , uh , here in a few weeks. Uh, we'll , we'll dive into, to , two give you some better value there. So , uh, let's talk about the podio platform, why these gaps evolve and ways that we can kind of go through these and solve and start with you, Alex.

Alex Shull:

Yeah, I think just at a, at a high level , um, the way that we'd like to approach these as always to think about the business needs first. So we're going to , we really want to spell it the business case. When we tackle one of these problems that's really Jareds forte. And once we understand better what the users actually need, then we'll do a little bit of the technical analysis. We'll , we'll discover in the podio API or in another system that you may be integrating with or whatever your use case may present additional constraints. We'll look at what those constraints mean for solving the problem and the different options you have available to you. Um, podio is a platform that has a lot of flexibility on it and I liked the fact that they've made some decisions with the API that grant you that flexibility. And I think that today's topic will really elaborate the fact of , of how that creates what may at first appear to be limitations but are actually just constraints that you have to understand how to work around and how to use the features that are there in Podio to solve your problem. And beyond that, I want to use the these episodes as an opportunity to paint a picture of podio in the context of a broader technical logical development that's going on in the industry in general in the cloud development industry. This is a picture that you see painted by Amazon web services. You see it being painted by Google and, and , um, Azure, the Microsoft offering as well. And the idea is serverless. Everything's going in the direction of serverless and what does that mean? I'm not going to unpack all that right now, but I'll leave you with a few thoughts in the serverless space. What has been addressed really, really well are the functions that get the work done on the back end, how they get the work done, how you access them and element that really has not been addressed. And maybe by intention is how you can define deployable front end solutions that capture the needs of the business. I think podio fills that space perfectly. And I think that as podio develops, is that platform the way that we use it as we position it in that front end p space for a serverless , um , solution model. Um, it, we don't need it really to change. We just need it to be extended to solve some of these repeating problems that we see, especially in the enterprise space. But I want to paint that picture over the course of these episodes and I just wanted to kind of give a , the big picture and I'll, I'll be going back to that vision.

Gil Roberts:

Yeah. Jared. Uh , from a design standpoint and business standpoint, what are some of the advantages that extending of podio platform could give clients of agencies or the people in the, of the developers and the people in the IT departments at enterprises? How could those extinctions , uh, help solve some of the business problems?

Jared Duker:

Well, first off, I've been working with Alex for a few years now and I love how we're able to say the exact same thing with completely different set of vocabulary and hopefully we don't talk past each other too much, but I want to bring it back to the idea of podio is an enterprise level solution platform and that is where most of these gaps come in. And what I really want to focus the discussion around , uh , because if we can make podio completely acceptable to an organization, rather it has 50 seats or 500 or 5,000 seats, it completely changes the environment that we're working in. Uh, in terms of developing solutions on the podio platform. And that's why extensions are so necessary because podio was never really envisioned to be a mass market product. It's intensely customizable. We love it for that. But at its core, it wasn't meant to fill the, that that mass market gap. The thing is, is it's 95% there. We just have to color in the 5% and that's where the open API is so critical and the fact that we can build these plugins and quickly get them into the market to fill in the little gaps that exist. And I think that's what we're gonna be talking about today.

Gil Roberts:

Yeah, absolutely. I personally, I draw a comparison to almost like a wordpress, a similarity where you have this kind of standardize body and then you can attach all the appendages that's required to actually solve the specific business case.

Alex Shull:

Yeah, I , um, I would take issue and I expect the Podio. Core developer teams would take issue with the comparison to wordpress, but I'll leave that for them to pick up. But the , the idea is very, very similar. Yeah. From the, from the standpoint of the user experience, very similar. You're giving them that, that container with the tools and the tools work good within that framework. And there are certain guarantees you get with the downstream systems when you use that. Yeah, absolutely.

Gil Roberts:

And then its ability, I guess , uh , let me clarify with that. It's , it's almost that ability to create these plugins based on an standard bodies .

Alex Shull:

Yeah, that's actually where I would say it's clearly superior to wordpress actually because they did a much better job up front of defining the surface for that integration and then saying that here's how it's supported and here's what you have to do to meet our standards for the integration.

Gil Roberts:

That's fair. So, uh , when we talk about podio platform extensions, W we've noticed a lot of different kind of granular use cases and also a lot of use cases for extinction and had not been addressed. There are much larger that the community wants. We're going to dive into a big one here in a moment, but what's what's think about some of the extensions that we've done in house for, for our clients, just as a way to seed some of our listeners mind about what we're about to jump into. So different types of integrations that done with other platforms.

Alex Shull:

Yeah, well I think the , in a , in a broad way, what we've found is that there, there, are there certain areas that have served very well for podio today? Just by Globiflow procfu, Integra Matt , Zapier, if you want to go there, they're there . Even further extensions that tie in very well with that open integration model, the podio supports and typically what I've seen there is that there are two, there are different flavors. One is the what I would consider the integra matt/Zapier flavor where they're basically saying we'll listen to any event and we'll call any API. We're not particularly good at doing any one of them, but we'll handle anything for you. And they have a very, you know, rigorous base model of performance and for charging page you go.

Gil Roberts:

That's kind of like the Swiss army knife for it. Yeah. It's not the best knife that you can get in constantly. Little plastic toothpick. Right. But you know it's there, it has the scissors and as the saw, yeah , it gets, it gets a lot done.

Alex Shull:

Yeah.

Gil Roberts:

Particularly well. But it does get a lot done and

Alex Shull:

I consider those just to be kind of integration marketplaces and they are useful for just doing prototyping and tying together occasional system integrations, things like that.

Gil Roberts:

Yeah . I want , I want to pause on a point because Jared, you had a , um, an example where we had a client that was using Zapier to do some Google doc. A replication that worked well in the lab was Zapier , but as soon as we put it out on the battle front and just collapse , yeah, yeah .

Alex Shull:

So that , that's one flavor. But what I would say is that if the other flavor of the extension is what procfu and globiflow does, which is very, very biased toward supporting podio primarily. So pro podio is the starting point for both of those. And then they have good integrations for the other systems on the back. Primarily we're talking about procfu, reaching out to other systems globiflow does a light work, you know, if they will reach out our eternal and all it did to , it drives internal automation logic. Yeah. And then a lot of the work you want to do is internal, but if you want to branch out, you want to start touching these bigger systems than you , you either have to , um, build your own integrations. You have to look at procfu or you can use globiflow versus doing some minimal post interactions. And so that's, that's kind of a, what I consider a podio first integration format. And then there's the , the total accustomed ones , which is the direction we're going in with Sassaafras where it is , um, a podio first. But we then say, you know what, Google is so valuable to our clients. We don't like this very low level integration in Zapier provides. That doesn't really fully complete the tasks that our clients need to compare . So much more than , and a lot more there. And so we started building a little more complicated. They do a little bit more than procfu, does procfu is very low level operations from primary. Yeah. Yeah. Something you have a little more complicated branching logic. And those are, it's between something that is just a slightly more advanced version of what Zapier does for you. Starting from podio by providing good Google integrations as an example. But it's below the level of doing what we would call bespoke integration, where we're just running custom functions for you on our Amazon backend. And so we had started to develop these building blocks that are more advanced than what you get from Zapier, but not quite the, you know, the , um, the complexity that you get from, for instance, doing the Google calendar direct integration to podio.

Gil Roberts:

Sure.

Alex Shull:

If that m akes sense.

Gil Roberts:

Yeah. We use this tool set , um, as the way that, and the reason I want to connect this back to the lizards , we use this tool set as a , as a way to solve these gaps, right? And that's where we're kind of discussing this. Now I want to turn it over to you, Jared. Uh , you've got some comments and , and just talk about the business case.

Jared Duker:

Want to get into this gap. Uh , do we want to read the original message? I mean, it goes way back.

Gil Roberts:

I can, I , if we want to go ahead and jump into let's go ahead and do it. Without further ado, let's get into the meat. So we actually, I'll just introduce it. Uh , Jared was talking about the business case. I'm sure you could probably think of just some examples off the top of your head, why this is important. Uh, and then , uh, just for our listeners to understand that before now we're going to define the business problem. We're going to explore some of the technical limitations that may be causing the gap or why it hasn't been solved or or whatnot. And then we're going to outline some potential solutions for something. At the end. We're going to dive deep into the API style solutions. So we'll list a few, and then one of the last ones will be that API solution. So , um, if you're interested in certain pieces, that'll give you the sign post of how this conversation is going to go down. So without further ado, we're going to pull up the most epic, a two way sync with Google calendar. It's Google apps . If you're looking through the community posts , uh , we'll have down in the show notes and actual direct link to the post, uh, and I do apologize if I butcher anybody's name or screen name. I'm gonna, I'm gonna read the original one and I think it's Alicia Gargus. Uh, massive. Garvis I'm not going to , I don't know either. I think so. I it'll be fun each episode and be butchering names. Um , so April 2nd, 2013 and it looks like 2:31 AM probably a time zone difference. Uh , she posted, I have integrated Google apps with podio, ga, Google apps, but when I edit a contact, in podio , the contact is still missing in my context on Gmail and next mobile . Another missing feature, which is where we're gonna focus on today is a two way integration with Google calendar. I would like to add or the wheat. Um, there's a typo there to Google calendar , uh , I guess appointments to Google calendar and have it in podio as well. And uh, I'll extend cause there's a ton of comments. You've got three people.

Alex Shull:

Really this is just the starting point of our conversation. Right . And there were a lot of votes on it and there've been a lot of comments up to including one just four months ago, and a response from Sarah at podio as the official comment in August, 2016. And that's a, that's an important point because it informs the types of solutions that will speak to as things change of podio. The kind of solutions that we suggest will change. But so what's , what's the , uh, what's the business case here?

Jared Duker:

Let me break this down a little bit about exactly what we're talking about here. Anyone who's worked in podio a little bit has probably linked there . Podio calendars to an external calendar service. We're going to be using Google calendars is , uh, a bit of our Straw man today just because it is so widely used and creating podio , uh , appointments or events and pushing them to Google calendars works fantastically. Everyone loves it. It's great. I've used it in five or six different integrations now. And it just really, really serves its purpose. However, we hit a hard line issue when we want to push Google calendar items back down into podio. And there's a couple of classic reasons about why this is so important. Very frequently a podio calendars are not the primary calendar that a business is using for variety of reasons. Um, they have a group calendars that maybe just however long established and are having trouble from an organizational standpoint , transitioning over to using the podio calendar or even more commonly, they're using an external calendar or scheduling service that is creating Google calendar events. Uh, and they want those to come down into their podio because they want podio to be their primary calendar service, but they ended up having to recreate all of their events inside of podio. Yeah , because there's no way to sync it both ways. A classic example of this , uh, just to bring it into the real world is an organization I've worked with that hire the drivers to take people to medical appointments. They would schedule the appointment inside of Podio, but the driver didn't have access to podio. They only had access to the Google calendar. So if anything you to change from the driver's perspective or if thing you get to make an update, then would update g calendars which would cause a Dan and the sync between the two. So very frequently the , the internal users would be looking at the podio event and not seeing any of the updates or mentions or warnings that the drivers may be putting yet. Right. Because there's not that two way sync. So I'm going to just throw the basic question to you, Alex is why is this so hard?

Alex Shull:

Yeah, that's a great question. Um, so I , I want to say that theirs , if you dig into this from the technical perspective, you want to understand where the constraints arise. And I'm going to start on the Google side, actually people other Google calendars. And from an enterprise perspective, when you're wanting to break this down, I used to be in an enterprise architect and you talk about the capabilities of an enterprise. You can talk about the capabilities of a small and medium size business as well. But here I think it's important to distinguish that the drivers are dealing with the capability that it has to do with scheduling operations. It's a real time operational concern. And then on the podio side, primarily we think of as data capture concerns. The calendaring in this case is split between the two because you have data concerns, but you have this operational element that is driven by Google calendar. In this case that's what the business wants. And so that define the use case for you. So in this case, the, that if we look at what the Google Api supports in calendaring, it's very powerful, but the , the core breakdown that will help people understand this limitation is that in Google there every calendar has an id and then there are events that are go to that calendar and you can do all sort of the permissions control to determine who can see those events and who can, you know , respond to those events and updates those events. But at their core events have unique ids that are belonged to calendars on unique , that have unique ids. When you take that back to podio and you look at what podio does for calendars. Here's the surprise, Podio doesn't really have calendars. If you look at their API, it's all online and you can go to developers.podio.com/doc/calendar and it will show you all the core API operations for calendars. And the one that's well explained to you best what's going on is if you go to the explanation for get global calendar, get global calendars , a call that has made on the behalf of a user, which shows them all of the items and all of the tasks that are visible to them

Jared Duker:

That's tied into their account?

Alex Shull:

Tied into their account. And so that means as an example, when something appears on a , on a calendar in Podio, it is driven either by a date field in an item or it's driven by a task and it doesn't actually belong to a calendar at all. Items with date fields long to apps and tasks belong to the task service and they can be referenced to items that can be referenced to spaces. And so when you look at the global calendar, you're looking at a dynamic amalgamation of data across podio, dependent upon the user's level of access. When you try to sync that with Google that has a static vision of a calendar which can be shared across people, you immediately run into a conflict. The conflict is either you have to constrain the vision of what a calendar can be in Podio, or you have to break your security model. Now, for me, it's an easy choice. I don't want to break the security model that because once you do that, you can't go back and it introduces all sorts of vulnerabilities downstream. You don't want to do that. I don't want to do that. And so you , you are . What you have to do is you have to accept the constraints. Now, we call it a constraint, but really as a developer, what I understand is that it's actually an opportunity to make a decision about what your integration is going to look like. It's a constraint because it's not, you're not nailed down into one way of interpreting. Let me give you some examples in your scenario for this two way sync. Let's come up with three variations over exactly what the users want in their sync. We can't talk to Alicia here. We can look at some of the examples in the comments, but I think there , if we break this question down into three variations, we're going to find that there are different ways to solve the same problem. First of all, some people in the comments say , you know what, I just want to be able to edit my items from podio. I want to build an open my podio calendar , edit the items, and have Google reflect it .

Jared Duker:

I think that happens pretty well right now .

Alex Shull:

It does happen. I was going to say that, and that's the official comment is when they updated that future, they're updating things like that and Podio, so you can just wait for features to come along and they will come along and that might answer your concerns if you're, if that's what the minimum requirements are for the business skills

Gil Roberts:

And, and people have responded positively there . I'm looking through the comments, now. Respond positively. That was uh, not three years, but we're , you know, three calendar years at this point are our three count account yours . Um, but that's really only half way . Yeah. Right, right. And I think the largest complaints , um , have come from that.

Alex Shull:

When people say two way sync, they want, they want, they basically give , you go to your business and you say, how do you want to use it? And they say, I want to be able to edit items in podio. So what do you want to also edit items in Google? And they say, well of course. So they want two way sync that means they want to edit in either place and have it propagate back. And so when we understand that there's a disconnect between the model of a calendar in Google and the model of calendaring in Podio. Go ahead

Jared Duker:

Let me redefined that. Just so that we're very clear when we say that, when we say podio doesn't have calendars, but we mean by that is in Google a calendar event is a very specific thing. It has properties that are known and they're universal. Every Google calendar event has the same properties that we can, we can manipulate, but it more or less looks like a calendar event. Yeah. Podio has a blank sheet that we happen to have put a date field on and are now calling a calendar event.

Alex Shull:

Yeah, and I , I would, I would distinguish between whether you're using tasks or items because it's going to lead the different solutions. If you're everything you're talking about our tasks in Podio, then when I'm about to say doesn't apply, I'm working on the assumption that you're dealing with more than just tasks.

Jared Duker:

I would say that we start with items, yes . That people be care about items sinking a lot more than that.

Alex Shull:

That's my assumption as well, and so giving them a , we were talking about items and we pushed tasks to the side. Then the the point is that with an item, the date field drives the inclusion. And so if you want to have a podio sink into a calendar where it is manipulable, then given that we have a client right now that we're , we're trying to address the solution for two ways saying the model that we want to go for is , is the following, that when you perform your , um, your synchronization to a Google calendar, you get a personal copy in your Google calendar. That means that essentially they're in the podio side. All of the calendaring is the shared element. That's where the sharing and the permissions occur. But that means that you get a very easy integration back into the Google calendar when you specify where the individual calendars are you're sharing with and they're a sync synchronization can be managed. If you, that means that again, that's one way, that's one way and, but that's a , that's a solution that satisfies, we'll be able to provide that is an automatic solution. Meaning that you don't have to provide any more levels of configuration information in order to enable that kind of synchronization at that level. It is easy to automate picking up the data out of the global calendar and if you edit the items in the apps , mapping them back to the unique events in your personal calendar and making sure that the permissions model isn't broken. That's a, that's a, that's scenario.

Gil Roberts:

Across a group, right? Yeah. You got it. Everybody has their individual calendar, you know, no control.

Alex Shull:

Yeah , there was , yeah, we're , we're making the assumption that , that you are using the same email addresses for permissions in Google and in podio. If we would do, if those permissions gaming map. And that's something that we can satisfy , um, that that's, but I don't think that's gonna work for everyone. And I think , um , what the case you were talking about Jared earlier, I don't get with satisfy them. And I think the reason is that you have an even more specific flow for the update process, which is the following that um , when an individual user picks up their item out of a given Google calendar , the style of the item may be different. It may not be that item may map to a totally different APP as an example. And as a result of that , um, we actually want to think of the integration style for that use case as starting from the Google calendar. The Google calendar defines the sharing. This is to me a bespoke integration. It means that we are talking about the same API constraints but it's one that requires a level of configuration that is so specific that it's hard to turn it over as a Sassaafras solution. One Click, you have integration to Google that I don't see it a possible, and I'll give you the reasons when we want to map the special Google calendar events into a podio workspace that is a mapping. You have to configure that. And then when you have an update propagated from work. So let's say we have three workspaces and one is a workspace for a, the drivers who have , um, events that are scheduled, driven out of the calendar event. The second one is an appointment that may result from the , um, the, the person's outcome from that event, maybe driven and um, then you may also have a, maybe a set of information that needs to be completed on a calendar before they're driven. So you have dependencies between them. In that interim event, you have someone up the counter of a event to say that I'm not going to be available to drive someone as an example. You want that information to propagate through the system and you want the podio logic to capture that information and maybe to change other dependencies that are in that calendar and system. You're not asking for just directly a two way sync. You're actually asking for previous logic to be rerun and to um, reapplied and change the business case and the business status. Is that correct or am I overthinking?

Gil Roberts:

Well , what I'm thinking is like an app in that case where it automatically finds the next driver available in slots in them in, right. It looks through everybody else's calendar. It looks through all those , uh , maybe pre-appointment dependencies and slots them in, because this guy say , hey, I'm not available, and it's , and it puts them in is that is that kind of thing ?

Jared Duker:

I don't think that's going to be a major issue. What actually matters is on the Google calendar, if someone was assigned to be the driver on an appointment and they click not available, That a category field could be updated on the podio item that says declined. At that point. We can use procfu, Globiflow, Sassafras, whatever, whatever functioning software we want to to drive logic. But right now, nothing that's touched on a Google calendar will be reflected on the podio item. So all of that power, all that horsepower that we have sitting there to do logic like Gil just mentioned is , is useless because we no way of firing off the event to update that part .

Gil Roberts:

But they're not listening for that. they aren't listening for that Google calendar update. And that's , that's kind of what it says here and there comments, um, you know, here's, here's one from , uh , just two years ago, you know, that's been going on for six years , uh, from , uh, of course I pick somebody with a little crowd, a crazy name is the second to last. Um, it says it is very nice to have it in one direction, but please keep up the good work. Um, it's something done halfway. Uh , you know, an event in Google does not sink into my calendar here on podio. Um , you know that this is what they're

Alex Shull:

Okay Jared, let , let me, let me take another crack at that cause I think I understand what I missed in the analysis. They basically , um, it's all Google driven events. [inaudible] I missed that key point. So obviously right now in today's world, globiflow procfu, they're not listening to the Google events. They're there . They're podio first in that regard. Um , Sassafras, we, we, we can listen to Google events. Um, which means that our Google apps integrations are driven by the model of having a service account. So if you have a full Google apps account, then you can create service accounts which can manage resources. You create one of those accounts and it's a very secure way to respond to and um, you know, take action on your Google resources at an enterprise level. Short of having one of those, all of these things are driven at the individual level in terms of what individuals have access to. And so the split comes as to whether the enterprise, the , the group supports the full Google apps or not. So speaking to the Google apps version, if we have a service account running, those are events we can listen to you. We can monitor the changes to those calendars and we can achieve downstream of that's , it doesn't change my answer. And in reality, it's still a bespoke integration. And the reason it's bespoke is because you're a customer event types in the, in the, in the Google space, even if you're listening to events on that side, it's that custom mapping between what is the application and podio and what is the event you're talking about in Google. So you can drive it from the Google side, no issue. It's that mapping that podio as a, as a principal cannot provide a turnkey two way integration with Google calendar. So what if you provide that mapping, then we can actually have a two way integration with Google and it, but I don't see an easy way of making it bespoke. There's , there are too many key issues that are gonna drive the specific business cases.

Jared Duker:

Let's, let's talk through how we could achieve this in a relatively simple term. It's never going to be currency . Yeah. I think we can safely say that this kind of two way integration, not something that's going to get rolled out by Citrix any time soon because of that, because of the complexity that we're discussing right now. Yeah . But we have a podio account with an email address and a Google account using the same email address to log in. So we have a natural tie in between the two. Yeah . We created a podio APP that has say a date field, a category field and a text field just hypothetically, so date what type of appointment it is and some notes about that appointment. These are three known , uh , podio fields with external ideas that we can look at when I create the Google calendar. Oh , sorry. When I create the Google calendar, integration is essentially spinning up a new Google calendar under my account's email address. It does , it creates a calendar service , uh , right there. So the tie in exists, podio knows to push these events to this calendar based on this date. And I believe it also includes the necessary information such as the , the text field goes into the appointment text. Some of the stuff like category fields, there does not seem to be as strong analog between the two service systems. We could overcome this with I think a little bit of massaging of the Google Api , uh , in terms of bringing that back.

Alex Shull:

Yeah. And , and, and that, so for a truly bespoke integration, I wouldn't use any element of the built in integration. Um, in all honesty. And the only reason I say that is because you don't want to integrations going on simultaneously. And so if the, if the, the built in integration with Google is not satisfying your, your, your needs and you turn it off and, and have one that's bespoke. And so the principles of that integration are actually the same. They don't happen to run on in the same runtime necessarily. We would run those in Sassaafras for us. But the idea is that when you're in Sassaafras, you have to put in credentials to determine what podio resources you manipulate. And you also have to add in Google resources, whether that's a service account or not. It doesn't really change what you can call as far as an API. You call it the same Google Api Apis. And so the the level of integration becomes again which side is first. If it's Google first, then you really want to define the Google calendars and listened to events there and drive podio changes if you want it to be driven from podium from Google and Google calendars have unique ids and everything and so it makes him as very fixed resources. So if you want to have the sink back into Google, which is the primary thing, the events style of events that you create on the Google side need to have enough information in them to map back to a specific application in podio. That's the only way to do it that I haven't figured out. If you have enough event information to where the integration layer and Sassafras can say, I see that there's, you know this text in here or this is in the subject or these people are invited, whatever the determining factors are, you have a little logic in there says therefore I'm going to map it to this app and then you can perform a sync because you have enough things to information to look up the unique id. Make sure the fields map and take events. Either way, you can listen to those item changes on, on podio and you can listen to those event changes on Google. This is what I call it biased integration because it makes very clear assumptions about what is the right way to integrate. There is no right way to integrate. It's an open, flexible system. You get to make choices and that's why it's good for developers, but people want turnkey as well. In this case, that's what I would envision as , um , the , the closest way to meet your, what you've described as a business card

Gil Roberts:

Something that would come out of the box. We would have to kind of define like those category fields. Like you have to have this category field in your podio items or a defined out of the box, true two way sync you'd have to play inside of some of those rules , uh , which, which does defeat some of the flexibility, right? Like I have to have x number of category fields every time I want to do this integration. If you have somebody who's a designer or developer or they may not understand it very well , uh , that , that's going to collapse on itself. Which, which makes sense as to why putting it probably doesn't complete the whole bridge themselves. Right? Because there's so many use cases out there and there's even a, a comment in the forms about that. Um, uh, Alexander calls and says, you know, to all the people that are complaining every part of user as your own specific requests leading to a big to do list for the podio team, I imagine this is more than a few days of work. So, most people understand that was five years ago. That was even before , um, uh , some of the newer stuff came out. So it seems like Podio is completed the bridge as far as they're comfortable for the reasons that you've described aleks that they're going to do. The issue back is because Google, I'll just it and say items. Calendar events are different enough in podio events. We'd have to have some kind of standardization to a podio item. You have to have these fields spelled exactly. You know, like in categories, you guys fell exactly. Capital's going to be in the right spot. Like all that. So

Alex Shull:

Yeah, you gotta make it machine. Understandable. And that's what I mean by that by a solution is that you reduce the flexibility by saying this is the way integrations work. And then as soon as someone comes along and says, well, that's not exactly what I need. And then there's another podio feature.

Gil Roberts:

Right . Right. And then that compounds. So it's very understandable why this hasn't been addressed over time. Right. Especially over the last six years. Now what can happen and we'll dive into, we're going to outline some of the potential solutions. We've kind of talked about it a kind of just looking at the limitation side right now, you , you could in some people have , um, jumped in with this app , your model, right? And maybe build some complex apps, especially now that it's accurate is the logic trees, which just came out, you know, in the last six months. I think that makes it solution level revival . Um, you know, but you now you've got five or six apps. Those apps have to go , uh, it's not real time. Right . It's zappier at best. If you buy their premium accounts, it's five minutes. We do a little bit of that with go to meeting, right. When you create a Goto meeting , it'll, it'll for us internally it over , it'll pop onto a podio calendar , but you have to wait. Right. And we were like, yeah , that's what I tend my desk for awhile . And then , then it shows up that

:

it's not a depressed scale. We're still above last replication. It's a barrier to be creating . Podio is at our press, the whole platform.

Gil Roberts:

That brings up a great point is I , if, if we built like with our Google integration and Zapier, Zapier you have to make a new Zappier your account or if you have a mass account and you have to make this zaps for every single copy of your solution, they to handle it by basically by hand. Yeah , exactly . What does and doesn't support something like that. And with him then as we talked about and the impact pro episodes , uh, globiflow and is also a bit of a barrier, uh, even with procfu integration to again, the replication side of that.

Alex Shull:

Yeah, there are two sides of it . There's the prototyping side, figuring out how to get things working wire in them up and then, yeah.

Gil Roberts:

As a potential solutions. Zapier is good if you're the only one that's ever going to use it, right . If you don't have any more locations, if you're a franchise or, or you have multiple departments, you don't have that or at least very few of them, right . Maybe two or three. If you get it , you know , start getting double digits in the nightmares come . Or if it's not a product or you're using it for multiple customers if you're in agency.

Alex Shull:

Yeah, I mean, I think we , we , we use zapier in those cases. But when , when you're , yeah, it's very, it's, it's, it's early quick, you know, and it's also when you don't necessarily know all your requirements and you don't. And as we get into it though, if we discover something that's important and we have any performance and you know, requirements around it, then we're going to try to move it off to up your , in today's world is everyone may change. But today , um , it is just a tool that helps us, you know, do things that aren't directly supported by those.

Gil Roberts:

Its that Swiss army knife we talked about and we're using the cheap little salt

Alex Shull:

It's lean you make it happen, you get , you get it working once, you know, show to the customer and then, and then you tried to make it work better using other technology

Jared Duker:

It works great on one off bills, but as soon as we start doing replication or scaling, brought it up ,

Alex Shull:

it's a very low investment just to get your , your POC at the door, your Alpha working, whatever.

Jared Duker:

So let's talk about what we can do today to get at least preliminary to way sinking from Google apps. And I think that the key to this is the date field itself. If nothing else, if someone reschedules and appointment inside of Google calendars that it can update the date in podio. Let's , let's just look at that because that should have direct data elements. We're not talking about strange category fields or anything else, but someone moves it in Google drive. It moves to the associated item in Podio to the new date through. Sorry, sorry. Yes, Google calendar .

Alex Shull:

Yeah. So if you go to the Google calendar and you grab an event and you move it than inside of Google in environment, that is a, an event that can be responded to and you absolutely, if you have that, that bias we were talking about where that event because of the information in that event can be mapped to a specific application that absolutely find the date field changed , the date field move , the date filled and podio. That's entirely possible that that is a, today that's a bespoke Sassaafras solution.

Jared Duker:

We could just use the external ids of the items to draw the associations between the Google of that podio item.

Alex Shull:

Um, we do . You could do it that way. Absolutely. Because there are going to be unique ideas that are fixed in both of those instances that may, you know, in every one of these cases there solutions , um, have to encounter our real customer. But that from what I said , that's the first thing I would try it.

Jared Duker:

So then from that we can extrapolate a few other real world situations because Google events, we'll have a subject line which we can universally map into an appointment name. For instance, inside of podio we have a uh , address a CC and BCC address line that we could turn into email address fields inside of Podio, date field we just talked about. So there, there's the possibility for as well sort of limited turn key integration. In my understanding,

Gil Roberts:

it's kind of like we were describing earlier where it's like the I , the , the APP in Podio is defined by the fields in Google calendar, right? And everybody , if you go in and start messing with those, that's when you could easily collapse. And out of the box solution, I start deleting fields. Like I don't, I don't want the BCC so I deleted , right. And now that integration is it sent sideways.

Jared Duker:

But going back to that scheduling service that I initially mentioned, if we could create a out of the box solution that uses a scheduling service to create Google calendar events and those events could be pushed down with and a title, a date and the email addresses of the people involved, that would cover the 80 to 90% business case requirement. Because I'm not saying people don't want, you don't want complete integration between everything Google and podio. I'm sure we can want it, but as long as we can create something inside of Podio, I believe that was satisfied most people's names .

Gil Roberts:

Again I got another comment from the user's forms that Kinda , that backs up and then it's around that line of thinking. This is from Scott Anderson about four months ago. Um , a little bit in front of that. But then he says this is a standard integration with any other software we use or have reviewed. So and I think it's that slim functionality of being able to just change something over on the Google side and change something on the podio side as a two way sync.

Jared Duker:

Yeah, which would be four primary fields. Again, the address field, the title field, the date field , l law informed note field because those exist on every single calendar, to a certain style ever seen.

Gil Roberts:

So basically for our developers out there that are a little more technical, you could start with this kind of core for all of your clients and probably something that the core that we'll offer for Sassy grass and then you then you can add those custom category fields and other things in a more bespoke way or any kind of other layers that you want to put on there.

Jared Duker:

The quick and dirty way would just be to parse the note field first . Specific thing is what we do when we do the update event, but there's better ways that maybe we could do it.

Gil Roberts:

Maybe use that note field as a container, almost a to put put some, some standardized and you know whether they asterix or something in front of stuff means this,

Jared Duker:

just like the Delta App functionality that exists now, they also a lot more robust fashion.

Alex Shull:

I wanna point of that one thing, and this is probably something that on the back end is leverage already by the ability and integration with um, Google is that every single item in podio has what's called an external id, which is a design is mapping field to external systems. And so when you, every item is generated, you can overwrite that external id and you can make that external id a link to a Google item, an event. And so there , there are all sorts of, you know, built in ways that podio supports this level of, of correspondence between external systems.

Gil Roberts:

So let's take a deep dive in. Just do a theoretical workout of this solution via the API. Just kind of give them what we got. Um, and, and kind of the business case. So what's just take those four standardized skills, we're going to give you office shelf simplified API integration through a service like Sassafras or were or developers out there listening something that they can build. What would be some of the things that they would need to understand about the API on both on the Google side and the podio side to make something like that happen.

Jared Duker:

And I'll just constrain that a bit more. I create an item in Google drive. Sorry. Sorry. I create an item in Google calendar it creates rather than Podio, I then update that item. It updates that item in podio. That's the functionality we want to achieve.

Gil Roberts:

Yes, that's, that's the gap.

Alex Shull:

Yeah. So technically already , um, you need a system that will listen to your Google events and respond to that which is not built in to um, the core solution . So that would be Sassafras or integra mat that involves a solution where you're able to , um , authenticate against Google. Now that, that happens with Podio, but they don't make the, the subsequent podio Google through the sacrament .

Jared Duker:

Well, let's define point there. We have to have an authentication with Google and an authentication with podio. So the accounts have to save that step one.

Alex Shull:

Yeah. And I guess , yeah, but again, that's a distinguishing in the service accounts and the individual authentications. So what this , the , the picture that you're painting in , um, the integration style requires a service account and a Google apps for business environment.

Jared Duker:

So you're saying that just my Google account that I made with my name and back at at Gmail is not going to be firing off those events.

Alex Shull:

You , you , you can do it that way or you're getting into run into issues. It's not going to be a manageable platform

Gil Roberts:

is that you need like a, a Gmail account inside of this Google app suite that is kind of like service APP ?

Alex Shull:

No, it's like that. But it's a service account. Yeah . You can actually log in as this account. So it is dedicated to running things on the back end and that account would then be the, the acting principal that on in Sassafras would receive events out of Google , um, regarding the events that it has, that it's tracking. So when it sees an update come in through one of those shared calendars, it would be able to find the matching event based on the external id of the item and the corresponding app. And you can find any item for that matter. And then it would have a mapping knowing which date field of the day feel got updated. Or if some other one of those mapped fields that we've talked about gets updated, you go update that item and the downstream events can happen listening for the update to that item. That can happen in globiflow, that can happen in procfu, anything that's listening , anything is listening to those podio items can, they can take it from there.

Jared Duker:

So one small complication there , I think that solves the business case that we just outlined very well cause we will set the podio items, external id to match the creative event in Google. How would Google store a podio created an event for that two way communication. So we created the event in podio. It then pushes to Google , uh, how has Google handle , uh , a set of what the equivalent of that external id so that we can maintain it ?

Alex Shull:

Yeah, totally . That was a podio item gets updated. Then in Sassaafras we're listening for item updated events. Sure we would have a custom flow. They would recognize this as being an APP that has a two way sync with Google. And so based on the external idea, that item, you'd be able to look up the event using the service account credentials that are stored with your sassaafras solution.

Jared Duker:

How does, how does Google store the, what their equivalent on external idea is that just marked on Google?

Alex Shull:

They're their items have a bunch of metadata that you can control. So there are unique ideas and I'll likely the , the , the strongest way for us is to maintain a little database in the Sassaafras back in that maintains that mapping between um , your items. But since you have an external id sitting there in Podio, you tried to put the information there. So the external id in the item where you heard the event should contain sufficient information to go look up your Google.

Gil Roberts:

Let me ask this question. Maybe you've already answered it. Um, if I create the event in Podio, how does it get that external id that Google , that Google equivalent of disturbance , external id stored in podio? If it's podio generated ,

Alex Shull:

Well then it's a new event. You generate the, the event and then you update the item .

Gil Roberts:

So basically now you've got two part where you've got to go. Okay man. Podio making Google calendar . Okay. That's making Google calendar. I'm listening for the new one. In Google calendar pull it back, you know. Yeah.

Jared Duker:

This is a, this is a logical system that it doesn't have a lot of branches to this tree. This is something it gets, if you bring it down to very simple, if then statements, if we were to draw the logic out and that's a good thing, that means it's doable.

Gil Roberts:

The the big constraint that we still have, even even if we give something like that out of the box , um, or if you create something that is to develop or listening, you still, if you need to apply that in different situations or different scenarios, maybe you have some category fields that you need to reflect on the Google side or something that you might want to change in Google. That's not kind of those four standard things. Uh , on the other side. That's where that bespoke integration has to come in and out. Now it's immediately become super specific.

Alex Shull:

you know, the, and of course, you know, the, the beauty of being in our position to see the different kinds of requests that come through is that when we're building for us, we're always trying to address that, the , you know, the solution that handles 90% plus of those scenarios. But then we leave it open to those custom integrations. We , we, we're , we're trying to develop our platform to where we can, you know, really give a high value quickly to the majority of the cases. But then as soon as someone says, oh, but I need these other things are the investment we've made just makes that even less work to do the customization as mine , it's mine . It's modular . We like to be able to build on top of our , our previous

Gil Roberts:

Heres your core , and then , okay, you need this extra kind of payload to go in with what's going on. We can kind of slap that on the side.

Alex Shull:

yeah , exactly. That is another layer on the cake. Right, and it doesn't

Gil Roberts:

hang on a lot of additional work to do. It does take some work.

Alex Shull:

Yeah. It's affordable though, as my point is that we're able to go in for those solutions that address those core features that are extensions of podio. Then someone says, oh, but I need some special sauce. It's like, well, we , we have special sauce, for you to.

Jared Duker:

We've gone into quite a few businesses now and don operational analysis on their needs and then delivered podio or other solutions to meet those needs. I could stay pretty clearly that just those four major points. What we talked about in terms of the Google integration data flow would satisfy the need to have pretty much across the board. There's always the light to haves . But if I could just offer them that sort of a high integrity to way sinking of date subject line participant and notes that the the need to have would be completely addressed. Uh , sure. I'll , um , well I'm going to be honest, I'm gonna try to up sell them the additional work that, you know , it could happen, but it really becomes, again, the need to have has been addressed

Gil Roberts:

and , and as the core, um, I, I want to end on one last point before we wrap up this episode, which is kind of kind of coming together and bring it at all. So to you, the listener facing this gap, we've presented some business cases, we've looked at the limitations we've outlined to potential solutions. What we boiled it down to and I'm like , I'm going to give us some here is basically if it's completely one off and you have no intention of ever replicating or scaling the solution, you've got an office of five people and it's always going to be that way. Seems like Zapier or cloud pipes or one of those types of that you're getting great. Do that right? Yeah .

Alex Shull:

Partial note to integra mat, but yeah, find the right solution

Gil Roberts:

and that's going to be and be happy with what's there. Right, cause you're not really going to get any better than that. If you are looking to scale to an enterprise level, multi location, or build a podio solution as a product that a lot of other people are going to buy, you got to come on that, that is not going to cut it . Do not invest your time to not waste the time outside of prototyping. Do not rely on that as a scalable way to do it. You must come to either a custom development yourself. You can come to us and look at Sassafras.

Alex Shull:

Well I'd say it's slightly different. I think you're right. But I would say go ahead and try it. And when you run into problems, give us a call.

Gil Roberts:

We are trying to bring some value to our listeners. There will be some people that will learn that way.

Alex Shull:

And there's nothing wrong with learning that way, cause you're not, you're going to be in a situation we can help you out of affordably still. So that's, it's all honestly . Yeah . You know, we , we , we can help a lot of people who are running into these issues. That's right. I do for a living.

Gil Roberts:

The value there, you know, that, that these are kind of your outs. So, so technically this is a solved gap now, right? Like in these are , these are the ways that we looked at it and these are the ways that we solve it. We will, for our listeners out there that wants something that's , uh , that maybe they're not as technically inclined, like Jared and I , uh, they can't do API developed themselves. Maybe they can't afford to do a full blown custom from the ground up. Um, development , uh , definitely contact us. Uh , we do have some solutions available. Um, otherwise, you know, take a look at how you would have to build it via the API yourselves. We've laid out a roadmap for you to be able to do that. Hopefully it's great value to our more technically inclined 100 listeners , uh , that that's kind of the way that it , that it needs to get done. All right , so appreciate you guys listening to our first , uh , of this series in our podcast of solving podio gaps. Next week we'll have two gaps right out of the gate. None of the fluff in the beginning. We're just going to solve two big things and we find in the user forms and we find out in the community forms or if you submit one to us, which we love to hear from you on our Facebook, Twitter, linkedin, you can also send a message, a podio message or any forms. Yeah, podio forms. Call us out at us. Say , hey, solve our gap brick bridge. Um , uh , Gil , Alex, Jared, might have you on the show of course, but we'll have two of those in an episode. Uh , so that we can move through more solutions. We do intent , uh , at some point to make most of these gaps live and available on our platform for those that are looking for that more out of the box field. But we're always here to drive some value and give you the roadmap you need to do it yourself , uh , that, that it's going to be there and available. And we do try to find things like Zapier solution for those and maybe not have the budget or just don't have the need to scale something out and try to find the fast and dirty for you . Uh , again, please submit your podio gaps and as always, if you have not and shame on you, if you have not subscribed to our podcast, please do so immediately by hitting that subscribe button. We also need your reviews and ratings ratings that helps us out more than, you know, some please leave us an iTunes rating or Spotify rating to help drive engagement with our show. And uh, we'll be back next week a special episode. We're going to dive into a industry case. I am we'll talk about more. When we get you into that. So thank you again for listening to Podio Solutions Podcast. Catch you next week. Thank you .