Podio App Builder

ProcFu's AppFrame is a point-and-click app builder that creates web apps connected to Podio — and other data sources. You define screens, connect them to data, configure fields and permissions, add server-side or client-side code where needed, and deploy. No framework to learn, no hosting to manage.

This page covers what the tool is and what it can do. If you're trying to decide whether you need a custom app at all, see Podio Custom App.

Podio App vs ProcFu Mini App

These are different things that work together.

A Podio app is a workspace structure for internal data storage — fields, views, filters, relationships. It's where your data lives.

A ProcFu Mini App is an external-facing interface built on top of that data. It controls what users see, what they can do, and how the experience flows. The data stays in Podio. The interface is yours to design.

Different purposes, complementary roles. One stores the data. The other shapes the experience around it.

Not Just Podio

AppFrame connects to six data sources:

• Podio — the most common source
• InfoLobby — structured data with built-in automation
• Tape — Podio-like platform, similar API surface
• Notion — databases and pages
• MySQL — direct database access
• Google Sheets — spreadsheets as a data layer

You can mix sources within a single app. A dashboard screen pulls sales numbers from MySQL. A detail screen edits the related Podio item. A text screen shows context from a Google Sheet. This matters when teams use Podio alongside other systems, which most do eventually.

Screen Types

Each screen in an AppFrame app has a type that determines its behavior. You configure screens through the builder UI — no code required for the basics. Code events (covered below) add custom logic when you need it.

Data List (Table)

The workhorse screen. Pick a data source, choose which columns to show, set default ordering. Built-in filtering and search come free. You can limit visible rows, and filter by logged-in user to create personalized views — each user sees only their own records.

When a user clicks a row, the app navigates to a detail screen for that record. Row selection is the primary navigation mechanism between list and detail views.

Detail/Record

Three modes: view, edit, and create. Each field is individually configurable — show or hide it, make it read-only, mark it required. You control which fields appear in which mode, so a create form can be simpler than the full edit view.

Custom validation runs via code events before save. After save, you can trigger workflows, send notifications, update related items, or call external APIs. Users can navigate between records without returning to the list.

Dashboard

Widgets for operational visibility:

• Gauge widgets — single metric display (e.g., "47 open tickets")
• Bar charts — trends and comparisons over time
• Detail tables — top items, summaries, ranked lists

Charts are powered by Google Charts with configurable colors, limits, and max values. Data comes from ProcFu variables set by code events, so you can aggregate, filter, and transform before display. This is where you build the "what needs attention" screens.

Text

Static or dynamic content rendered as Markdown. Magic tokens let you inject variables: logged-in user name, current date, session data, or anything set by a code event.

Use text screens for welcome pages, instructions, confirmation messages, or status summaries. They're the glue between action screens.

Date Picker

A calendar interface for selecting dates or time slots. You can configure available slots based on data — show only dates with openings, block past dates, limit to business hours.

The selected value is accessible in subsequent screens via tokens or session variables. Use for booking, scheduling, or appointment selection.

Barcode Scanner

Uses the mobile device camera to scan barcodes. The scanned value becomes available in subsequent screens, where you can look it up against your data source and display or update the matching record.

Built for inventory management, receiving, asset tracking, and check-in flows. Works on any phone with a camera — no native app needed.

Custom HTML

Full control. Write HTML, CSS, and JavaScript. Server-side processing via code events handles the backend. Use this for anything the other screen types can't handle: payment forms, interactive maps, custom UIs, embedded third-party widgets, or specialized data entry interfaces.

Custom HTML screens are the escape hatch. Most apps don't need them, but when you do, there's no artificial limitation.

Code Events

Screens handle common patterns through configuration. Code events handle everything else. They run ProcScript (server-side) or JavaScript (client-side) at specific points in the screen lifecycle.

Server-Side Events (ProcScript)

Before Process — Runs before any screen processing. Use for authentication checks, data preparation, conditional redirects. If a user shouldn't see this screen, redirect them here.

Before Render — Runs after data is collected but before the screen displays. Transform data, add computed fields, filter results, set variables for dashboard widgets. This is where you shape what the user sees.

On Submit Validation — Validates form fields before save. Return errors to block submission with specific messages. Runs server-side so it can't be bypassed.

After Submit — Post-save processing. Trigger Podio workflows, send email notifications, update related items across apps, call external APIs, log actions. The heavy lifting happens here.

On Auth Fail — Custom handling when authentication fails. Show a branded error, redirect to a registration page, or log the attempt.

On Auth Success — Runs when a user successfully authenticates. Set up session variables, load user-specific data, check permissions, redirect based on role.

Client-Side Events (JavaScript)

On Render — DOM manipulation after the page loads. Add event listeners, modify the interface, inject dynamic behavior, integrate third-party JavaScript libraries.

On Row Select — Fires when a user clicks a table row. Run custom actions, show confirmations, or control navigation logic before moving to the detail screen.

Code events are what separate a simple data viewer from a real application. Most apps start without them and add them as requirements get specific. See ProcScript documentation for the server-side language reference.

Authentication

Six options, from simple to enterprise:

• Single password — one shared password for access. Simplest setup, useful for internal tools where individual tracking isn't needed.
• Username/password — custom user database with per-user accounts and individual access control.
• Google OAuth — login with Google credentials. No passwords to manage.
• Podio OAuth — login with existing Podio credentials. Good when users already have Podio accounts.
• Secure email link — passwordless authentication. User enters email, receives a magic link, clicks to access. No password to forget.
• Optional 2FA — add SMS or authenticator app verification to any of the above methods.

Security

• URL hacking prevention — detail views aren't accessible by guessing record IDs. Items must appear in a table the user can access before the detail view opens.
• IP whitelisting — restrict access to specific IP ranges.
• Field-level permissions — control visibility and editability per field, per user, per action.
• HTTPS everywhere — all traffic encrypted.

Deployment

Multiple hosting options depending on the use case:

• ProcFu URLs — immediate, no setup (https://procfu.com/widgets/mcapp/APPID)
• Custom subdomains — branded under ProcFu (myapp.procfu.com)
• Custom domains — your own domain, pointed at ProcFu
• Iframe embed — drop the app into an existing website or intranet page
• Mobile-responsive — works on phones and tablets without separate builds

Most teams start with ProcFu URLs during development and move to custom domains for production.

What People Build

Real use cases from production apps:

• Customer self-service portals — view invoices, place orders, submit and track support tickets. See Podio Client Portal and Podio Customer Portal.
• Employee portals — time-off requests, document access, timesheets, policy acknowledgments.
• Mobile field apps — daily check-ins with GPS, barcode scanning for inventory, receipt photo submission.
• Operational dashboards — sales metrics, project status boards, KPI tracking. See Podio Dashboard.
• Podio enhancements — master-detail spreadsheet views, linked item creators, bulk editors that work faster than the native UI.
• Public-facing apps — booking forms, product catalogs, event registration, map-based listings.

For a broader gallery, see Mini App Use Cases. For portal-specific guidance, see Turn Podio Into a Client Portal.

How It Fits Together

AppFrame handles the interface layer. Behind it, ProcFu Flows handle backend automation — scheduled syncs, webhook processing, multi-step workflows that run without user interaction. Together, they cover the full stack: user-facing apps in front, automated processes behind.

The data stays in Podio (or whichever source you're using). ProcFu is the application layer on top.

Getting Started

AppFrame is included in all ProcFu plans. The AppFrame feature page has a walkthrough of the builder interface. Plans and pricing cover what's included at each tier. Start a free trial to build your first app — no credit card, no sales call.