Pushing Podio

Fun Experiments pushing Citrix Podio to the limit so you can get more done.
... with a little help from GlobiFlow, ProcFu, and other friends ...

Advanced Mini App Ordering System

- Posted in Uncategorized by

In this post, we're going to push ProcFu's mini apps a bit to showcase what's possible, and also share some hacks and tricks to get more out of them.

We're going to set up a customer portal where users can review and place orders, allowing for multiple items per order.

The result we're going for looks like this:


The setup in Podio is quite simple.

  • Users App (for authentication, with username and password fields)
  • Orders App (links to Users, with date and status fields)
  • Products App (list of products with name and price fields)
  • Order Items App (links to Orders and Products, with quantity field)


There are also a few calculation fields for convenience.

The mini app will take a few iterations, so I'm going to explain it step by step.

Step 1 - Authentication

For authentication, we're going to use our Users app which has a username and password field.


Step 2 - My Orders List

The first screen will be an overview of existing orders. So we just display it as a table of related items.


And we'll set this myOrders screen as being the first screen when we log in.


By now we have a simple app where you can log in and see a list of your orders.

Step 3 - Create Order

Creating an order is quite complex and we'll have to work backwards a bit.

We'll need a table of order items related to an order


Then we'll need a build order page which will just show a view of the order details and embed the order item list in the footer


To embed the order item list in the footer, we use the @[pf_embed:SCREENNAME] token


Then we'll need a screen to create a new order which on submit moves to the build order screen. We pre-fill the fields and use javascript to submit the form.


Notice that all fields above are hidden. This whole screen will only appear for a second and is not intended to be interacted with.

Using the @[pf_current_date] token for the date field inserts the current date, using the @[pf_auth_item_id] token sets the user of the order to the currently logged-in user. We also set the status of the order to New.

The javascript has 2 purposes:

  • hide the submit button of the create form
  • submit the form

Here is the code:

$(document).on("pfEndDelayed", function() {

We'll also need an add item screen to create new order items linked to the current order


Using the @[pf_app_item:APPID] token we can link the new item to the current order (replace APPID with the id of your Orders app).

Also set the on submit of the screen to the build order screen.

Step 3 B - Connecting the dots

Now that we have screens to build the order and create new order items, let's go back to the build order screen and add a button at the bottom (after the embedded item list) to link to the add item screen. We also add a little javascript to hide the default back button on the order details. We only want the user to be able to add new items from this screen.


The revised footer code is now:


<button class=primary>[Add Item](@[pf_screen:AddItem])</button>

$(document).on("pfEndDelayed", function() {

We also want to go back to the main list orders screen and add a button in the footer to the new order screen we built earlier.


Step 4 - Complete Order

So far, users can start adding an order, but are always stuck on the order and can only keep adding new items. In order to provide a mechanism to complete an order, we'll add another auto-submit screen to automatically change the order status to Confirmed, and navigate back to the main orders list on submit.


This is another screen we don't want users to interact with, so we also hide all buttons.

The code for the footer is:

$(document).on("pfEndDelayed", function() {

We can now go back to our build order screen, and add a button to confirm the order next to the add item button.


The new (and final) footer now looks like this:


<button class=primary>[Add Item](@[pf_screen:AddItem])</button> <button class=primary>[Confirm Order](@[pf_screen:confirmOrder])</button>

$(document).on("pfEndDelayed", function() {

Now users can log in and create new orders with multiple order items.

Step 5 - Order Details

To let users see the details of a previous order, we need to create a screen to show the order, and embed the list of order items underneath. Luckily we can re-use the same item list from before.


For convenience, we'll also include a button at the bottom to quickly get back to the main orders list.

We also now need to change the original my orders screen to link to the order details screen on submit


Now users can log in, view their previous orders, view previous order details, and create new orders consisting of order items.

The only part that I'd still like to add is in case of breakage. If a user leaves the session without confirming an order, it's stuck. This is not the best.

Step 6 - Unconfirmed Orders

We'll go back to the order details screen, and add a button called complete order, linking to the build order screen again.

But since we only want this button to show if an order is in the New status, we'll hide it by default, and use a little javascript to get the text of the status row, and unhide the button if it's still in the New state.


The code for the footer now looks like this:


<button>[Back to Orders](@[pf_screen:myOrders])</button> <button class=primary style="display:none">[Complete Order](@[pf_screen:buildOrder])</button>

$(document).on("pfEndDelayed", function() {
  if ( $(".pf-form-row[data-for=status]").text() == "StatusNew" ) {

If you ever inspected a mini app form row, you'll notice that each row has a data-for attribute for the Podio field in question. This lets us easily extract the text value of the row and build some logic around that.

The Result

See the mini app in action:


You can download the full-page screenshot PDF of the Mini App here: PDF