Deliverable summary table with hyperlinks



  • Ambiente Admin

    This is great - my question is why? Not negatively but there is a standard way of doing this using relationship field but you have done it differently and I think more neatly. Is that the only reason ... neatness or was there something else motivating you?

    good job!


    Comment actions Permalink
  • Kent Watson

    Yes good question Ambiente,

    I'm certainly no expert on setting Podio up.  And I'm keen to get feedback on better ways to do things.

    So to answer why I did it this way...  It is my understanding when using relational databases if you are using a many to one relationship it is considered best practice to established that relationship from the app (table) containing the many items not the one item. Therefore rather than create new deliverables via the project app, I create new deliverables from the deliverables app and reference them to the project item. It seems doing this in Podio also creates better grouping/reporting of the deliverables back in the deliverables app.  My only problem was that you had to scroll to the bottom of the Projects app to see the "Related Items", which can't be ordered in any way - meaning if a relationship is established from another app first than this appears in the list first etc (I have many apps referencing the projects). Also the "Related Items" list takes a minute to refresh and display those "Related Items".  So I thought the best way to put the data right where I wanted it, and maintain relational database best practice, I needed a table as I have achieved.  Also down the track I can add functions to filter out certain items (such as the cancelled deliverable), and possibly change the sort order of the items in the table.

    Thanks for your question and feedback.

    Comment actions Permalink
  • Ambiente Admin



    Thanks for the complete reply. I too have been irritated by the need to scroll to the bottom of an App in Podio to see related items. 

    I solved my version of the problem using Globiflow, and a relationship field. 

    I agree that the one to many construct is a 'standard' for those of us at a certain age(!). In my example I have various properties, each with (many) inspection recommendations. I wanted to show all the active recommendations in a summary format in the property app.

    I added a relationship field from the property to the recommendations. Then a GF script monitors updates on the recommendation app. Following any update of a recommendation, the script gets the parent property and then finds all the recommendations associated with it. Then it filters the non completed recommendations and write the list of recommendations back into the Property relation field.

    This took me quite some time to sort out! But it works well now. 

    The reason I'm interested with your method is that it uses less screen space to display summary data. and in some ways its more attractive. 

    I notice that Javascript and Calc Fields vs Globiflow and PHP are overlapping solutions in the Podio universe. I suspect and hope that we will see some harmonisation as the system evolves. Especially around these specific of what I would call 'real' database functionality.

    Maybe you've seen this page already.

    It describes (albeit in a rather obscure fashion) a very similar approach to the one you developed. It may give you some inspiration!

    good luck



    Comment actions Permalink
  • Kent Watson

    Thanks Ambient,

    Are you 21 also 😁, I had no idea following that many to one philosophy showed my age... maybe that I didn't know shows it even more!

    I don't have a subscription level that grants access to Globiflow. I see its power from a demo I had, but yes I did find it difficult to get into the advanced functions.  I was unaware it was based on php, although it makes sense as I'm guessing it is processed at the GF server not at the browser as JavaScript does. 

    Yes that post was my inspiration, thank you for the reference.  I also found it obscure and hard to follow, which was kind of my inspiration to write this post, so I had something to come back to that Mae sense to me.

    Have you got a screen capture of the result you managed to achieve with globiflow? 

    Comment actions Permalink
  • Matthew Cock

    Hi Kent - you suggested I look at this solution in relation to my question. Would you mind humouring my less technical brain by saying whether or not this would solve my problem if I explain it a different way?

    So - what bugs me about relationships is that I can not look back at the  'history' created at any point - for example, if I was building a workshop app with 'workshops' and 'delegates' with many-to-many relationships. Over time people will have go to more than one workshop, and I want to record something specific about their relationship with each workshop (category; speaker, attendee, chair etc.). At the moment, I would have to store the category within the delegate record, for the most current instance of the category field. After the workshop is over, and the next time a delegate goes to a workshop, that category field may change.

    Do I use your method above (or simply do a calculation triggered by a workflow) to record a snapshot of the delegate/workshop relationship category?




    Comment actions Permalink
  • Rainer Grabowski

    Hi Matthew,

    you have to do a snapshot. For that you need either A) a "Delegate/Workshop-History"-App or B) a text field in the Delegates-App where you store a snapshot for each workshop the delegate visited.  A)  you can achieve with Podio Flows, for B) you would need Globiflow. If you prefer B) I recommend to store each teh entry for each workshop with the same structure like:

    Workshop: Workshop title
    Date: date
    Category: text
    xxx: text
    yyy: text

    This way you can use a calculation field to analyse the entries in the text field. If you prefer A) you can also use a calculation field for an analyze. 


    Comment actions Permalink
  • Hugo Breda

    Thank you so much for sharing Kent! It helped me a lot! Best, H.

    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk