Damn son. I feel Iike I just watched a $500 course. Only been working with Podio and Globiflow for about a week and a half. I come from a relational database background. And I knew that the relationship field was key. But I could not grasp the concept until this video. Actually, what I didnt realize was the degradation of the contact field and was going off older videos. Until this video, my apps were all flat and linear. You have caused me to go and delete all and start over correctly using the relationships. Thanks for all these videos.
Tom Loner thanks tom! Glad you’re finding these useful. We’re ramping up our production schedule for podio-based content. Let me know if there are specific topics you think would be useful.
@@Incomedigs Definitely will. I have gone in and revamped my setup with the centralized contacts. Making it look and operate much better. I am also trying out smrtphone. I just want an SMS solution and dialing solution under same roof. We will see. will let you know of additional content I would like to see. Thanks.
Tom Loner SmrtPhone is phenomenal. I’ve successfully implemented with several clients now. Will have some videos on it soon. Let me know how it goes for you.
Great video...I'm glad I found it. I'm a realtor and some of my customrs are both buyers, sellers & landlords. You advised us not to use categories in the central contact app....so how can you have one customer who falls into multiple categories...without having multiple entries for that customer?
Do you think it could make sense to create a separate contacts app for leads? That way you wouldn't have your main contacts app filled with junk contacts (unqualfiied leads). You could set up a workflow so that only once a lead is marked as "pre-qualified" (or some other trigger) it gets added to your main contacts app.
Yes, that logic makes complete sense. The "Leads" app could capture Name, Email, Phone, etc. Once the lead is converted, you create a new contact. Sounds good to me!
I only use the contacts app for my main records as you described in the video, but my Contacts app type is currently set to, Standard. Is it necessary or any specific reason to convert the app type to "Contact"? Or is this setting only used on initial contact app creation to pre-populate the fields?
Hey! Thanks for watching! Definitely the pre-population of fields is the main reason to use that app type. You will get fields like name, email address. Podio will not let you remove those fields. Its a good "validation point" to ensure compliance.
In the demo where you connected the relationship of deals app to the properties app, I noticed that you didn't connect the deals app relationship to the contacts or sellers app. Shouldn't the deals app be connected to the prospect, either the contact or sellers app? Which one would be the best relationship practice?
Thank you for this great video! It's really helpful in thinking about how to organize workflows... I was wondering.. is there anything to think about when deciding which "workspace" to put the universal contacts app in? Considering practically every workspace would have at least one app that links to contacts, members of our team from every area might need to access the contacts app, I was thinking of having it stand alone in its own workspace. Does that make sense?
Yes...while it may not seem practical, you do need to think about access/ permissions when deciding on workspaces. There may be additional apps that fit this scenario, so a centralized workspace holding the contacts app is best.
Hey, can you please advise best practices for the webforms with this? I have a webform set up for new enquiries, so they add their name, email etc, is there a way once a third party has filled in their info in goes into the app (for example vendors) and then automatically connects to the main contacts app?
Hi There! Thanks for the question! Yes, you could have "mirroring" fields on your vendors app. Once a new vendor is submitted via the form, setup an automation to create a new contact and populate the fields that are coming from the webform. You would then connect the contact and vendor via relationship.
Another super simple, but potentially important, question.. in the contacts app do you think it might ever be necessary to have separate fields for first and last name? The default is to put them together.. but that would be a pain to separate later. (In case, for example, wanting to pull the first name from Podio contacts for an email campaign) However.. if I separate them I'd need to figure out how to get both names to show up on the card view. I guess that shouldn't be too hard!
Hi Shaheen, I definitely prefer to have First and Last name separate. This allows us to easily sort our list in alphabetical order by last name. You can then combine First/ Last name into a calculation field.
Another question: If you don't use categories in your centralized contacts app, how could you, for example export your client contacts only? If you export from your "client" app (which has a relationship field connecting it to your universal contact app) it would only include the first line of the relationship field in the export, so you wouldn't have the details like the email and phone number in the export.
You can use calculation fields to bring in whatever data you need from the contacts app. In addition, you could use a calculation field at the contact to determine the contact type. The idea is to allow the system perform the logical test for you...as humans are bound to make an error/ leave something gout.
Once the Universal Contacts App is in place and I have multiple contacts that don't fall into one of my specific contact apps, how do you suggest we organize them since they can't be found in the other apps, that by default, are already sorted by type. I am asking because in this video, you mentioned NOT to create category field in Universal App with Contact Type, and I am not sure if I want to make 50 different apps for 50 different contact types. Any ideas? Thanks!
Hi Sophie...thanks for watching! Can you provide a few examples of the different types of contacts? This may or may not apply...For example, you could have a "Vendors" app. The vendors app relates to your central contacts app with a field like "Primary Contact(s)". Within the vendors app you can then have categories to help you organize: E.g. Relators, Attorneys, Contractors, etc. Happy to help you think through a solution with specific examples.
Damn son. I feel Iike I just watched a $500 course. Only been working with Podio and Globiflow for about a week and a half. I come from a relational database background. And I knew that the relationship field was key. But I could not grasp the concept until this video. Actually, what I didnt realize was the degradation of the contact field and was going off older videos. Until this video, my apps were all flat and linear. You have caused me to go and delete all and start over correctly using the relationships. Thanks for all these videos.
Tom Loner thanks tom! Glad you’re finding these useful. We’re ramping up our production schedule for podio-based content. Let me know if there are specific topics you think would be useful.
@@Incomedigs Definitely will. I have gone in and revamped my setup with the centralized contacts. Making it look and operate much better. I am also trying out smrtphone. I just want an SMS solution and dialing solution under same roof. We will see. will let you know of additional content I would like to see. Thanks.
Tom Loner SmrtPhone is phenomenal. I’ve successfully implemented with several clients now. Will have some videos on it soon. Let me know how it goes for you.
Great video! Very informative. Subscribed, I look forward to viewing more of yr videos.
Great video...I'm glad I found it. I'm a realtor and some of my customrs are both buyers, sellers & landlords. You advised us not to use categories in the central contact app....so how can you have one customer who falls into multiple categories...without having multiple entries for that customer?
I guess you simply relate your Buyer, Seller, and Landlord Apps to the same Contact Item in your Centralized Contacts App.
Do you think it could make sense to create a separate contacts app for leads? That way you wouldn't have your main contacts app filled with junk contacts (unqualfiied leads). You could set up a workflow so that only once a lead is marked as "pre-qualified" (or some other trigger) it gets added to your main contacts app.
Yes, that logic makes complete sense. The "Leads" app could capture Name, Email, Phone, etc. Once the lead is converted, you create a new contact. Sounds good to me!
I only use the contacts app for my main records as you described in the video, but my Contacts app type is currently set to, Standard. Is it necessary or any specific reason to convert the app type to "Contact"? Or is this setting only used on initial contact app creation to pre-populate the fields?
Hey! Thanks for watching! Definitely the pre-population of fields is the main reason to use that app type. You will get fields like name, email address. Podio will not let you remove those fields. Its a good "validation point" to ensure compliance.
In the demo where you connected the relationship of deals app to the properties app, I noticed that you didn't connect the deals app relationship to the contacts or sellers app. Shouldn't the deals app be connected to the prospect, either the contact or sellers app? Which one would be the best relationship practice?
Hey! Definitely depends on the setup...but this would probably be done from the sellers app. You would indicate a field on the seller app for "deal".
Thank you so much! Great video. It saved my life though. 🙏
Thank you for this great video! It's really helpful in thinking about how to organize workflows... I was wondering.. is there anything to think about when deciding which "workspace" to put the universal contacts app in? Considering practically every workspace would have at least one app that links to contacts, members of our team from every area might need to access the contacts app, I was thinking of having it stand alone in its own workspace. Does that make sense?
Yes...while it may not seem practical, you do need to think about access/ permissions when deciding on workspaces. There may be additional apps that fit this scenario, so a centralized workspace holding the contacts app is best.
Hey, can you please advise best practices for the webforms with this? I have a webform set up for new enquiries, so they add their name, email etc, is there a way once a third party has filled in their info in goes into the app (for example vendors) and then automatically connects to the main contacts app?
Hi There! Thanks for the question! Yes, you could have "mirroring" fields on your vendors app. Once a new vendor is submitted via the form, setup an automation to create a new contact and populate the fields that are coming from the webform. You would then connect the contact and vendor via relationship.
Unless you playing solo placing your apps in one workspace is a big security and privacy issue
Another super simple, but potentially important, question.. in the contacts app do you think it might ever be necessary to have separate fields for first and last name? The default is to put them together.. but that would be a pain to separate later. (In case, for example, wanting to pull the first name from Podio contacts for an email campaign) However.. if I separate them I'd need to figure out how to get both names to show up on the card view. I guess that shouldn't be too hard!
Hi Shaheen, I definitely prefer to have First and Last name separate. This allows us to easily sort our list in alphabetical order by last name. You can then combine First/ Last name into a calculation field.
Another question: If you don't use categories in your centralized contacts app, how could you, for example export your client contacts only? If you export from your "client" app (which has a relationship field connecting it to your universal contact app) it would only include the first line of the relationship field in the export, so you wouldn't have the details like the email and phone number in the export.
You can use calculation fields to bring in whatever data you need from the contacts app. In addition, you could use a calculation field at the contact to determine the contact type. The idea is to allow the system perform the logical test for you...as humans are bound to make an error/ leave something gout.
Once the Universal Contacts App is in place and I have multiple contacts that don't fall into one of my specific contact apps, how do you suggest we organize them since they can't be found in the other apps, that by default, are already sorted by type. I am asking because in this video, you mentioned NOT to create category field in Universal App with Contact Type, and I am not sure if I want to make 50 different apps for 50 different contact types. Any ideas? Thanks!
Hi Sophie...thanks for watching! Can you provide a few examples of the different types of contacts?
This may or may not apply...For example, you could have a "Vendors" app. The vendors app relates to your central contacts app with a field like "Primary Contact(s)". Within the vendors app you can then have categories to help you organize: E.g. Relators, Attorneys, Contractors, etc.
Happy to help you think through a solution with specific examples.