Stacker Guides and Resources
Stacker is used as the frontend for most of PWI's Airtable data.
Stacker Capabilities
Stacker goes beyond Airtable's capabilities by offering many unique features such as:
- User Roles
Stacker offers custom user roles, which allow you to automatically categorize and group users based on specific properties.
- Permissions
Stacker offers CRUD (Create Read Update Delete) permissions for data. You can set CRUD rules based on user role or ownership of data.
- Custom Views and Visibility
Stacker allows you to control visibility of data and visual elements based on user role or specific data. This allows us to:
visually organize information to make it more intuitive
hide information that is not relevant to the user or to the record
highlight key information
build different views for different data types
- Built-In Forms
Data in Stacker can only be created through forms, which allows us to enforce data integrity
- Action Buttons
Action buttons act like pop-up forms and allow manipulating data in a quick and easy manner, or triggering Zapier automations.
Known Issues
- Unable to Conditionally Hide Required Fields
Stacker's newest update (December 2023) allows you to hide/show individual fields conditionally. This is available for forms, record detail views, and action buttons. However, if you make a hidden field required, saving the updates will fail erratically.
Development Standards and Process
New App Setup
Our Airtable bases often contain a large number of fields. New apps usually don't require all of these. Therefore, it's a good idea to disable all fields in a Stacker data table first, before you start building any views. Then, turn on only the fields you need.
When configuring views, make sure to turn off the "allow creating new records" option for all linked record fields backed by a synced table in Airtable.
User Filters
When setting permissions for an app, always use the filter "employee is not inactive" instead of "employee is active".
Don't forget to filter by employee type when appropriate!
As much as possible, use filters based on department and seniority to determine app roles.
App Color Scheme
App color scheme is generally based on the use case to follow our color palette.
color | use case | examples |
|---|---|---|
blue | requests | decal requests, IT requests |
green | data/metrics | metrics, active projects list |
orange | management | projects, inventory, shipping/receiving |
red | personal | ADP (pay stub/401(k)), vacations, wellness reimbursements |
purple | resources | PWI University, resource library |
gray | other | misc. |
App Naming
App naming and URL should be as concise as possible, while still clearly indicating what the app is used for. Approve all app names with Jeff before going "live".
Always include Jeff as an administrator in all apps. You can access this by selecting "Manage Users" in the sidebar menu, and then selecting the "Administrators" button at the top right.
Once an app is pushed to production, always rename it to start with a 2-digit number and a period (.) so it sorts appropriately in the list. This will help us to clearly identify which apps are in production and which apps are in development.
Normal apps can be numbered so that they sort as desired in the list.
All Temporary apps should start with
90.All Software Team apps should start with
99.
Callouts
Callouts are useful for calling attention to important information. In an effort to maintain consistency throughout our apps, use callout styles as follows:
Callout Style | Use case |
|---|---|
Error | For displaying high-priority calls to action or errors |
Warning | for displaying calls to action or missing data |
Success | for displaying success messages |
Question | (do not use this type) |
Brand | (do not use this type) |