Conditional Visibility lets you control which Destinations appear on Profile Pages based on Item data or the device someone is using. This is an advanced feature for complex routing scenarios—most users won’t need it.Documentation Index
Fetch the complete documentation index at: https://help.qrtub.com/llms.txt
Use this file to discover all available pages before exploring further.
When You Need This
You probably don’t need conditional visibility if:- You want different people to see different Destinations (just show all Destinations—people tap what’s relevant)
- You want to route to different URLs based on Item data (use URL Templates instead)
- You want to show completely different Destinations for different equipment types
- You need to display warnings only when dates are expired
- You need different Destinations for mobile vs desktop users
- You have complex routing requirements where showing all Destinations would confuse users
Common Use Cases
1. Equipment Type-Specific Inspections
Scenario: You manage forklifts and cranes. Each type needs a different inspection form. You don’t want forklift operators seeing the crane inspection button. Solution: Show “Forklift Inspection” Destination only for forklifts, “Crane Inspection” only for cranes. Condition for “Forklift Inspection” Destination:- Use the standard
typefield or add a custom field (e.g.,equipmentType) to your Tub - Set each Item’s type value (“forklift”, “crane”, etc.)
- Create separate Destinations for each inspection type
- Add the condition to each Destination
2. Tag-Based Routing
Scenario: Some equipment is tagged as “heavy-equipment” and needs specialized inspections. Other equipment uses standard inspections. Condition to show “Heavy Equipment Inspection”:- Tag relevant Items with “heavy-equipment” (using the standard tags field)
- Create a “Heavy Equipment Inspection” Destination
- Add the condition
"heavy-equipment" in item.tags - Tagged equipment shows this Destination; others don’t
3. Overdue Inspection Warnings
Scenario: You want to show a prominent “INSPECTION OVERDUE” Destination when equipment inspection is past due. Condition to show “INSPECTION OVERDUE” banner:- Add an
inspectionDuefield (date type) to your Tub - Set each Item’s next inspection due date
- Create an “INSPECTION OVERDUE” Destination (bright red, urgent styling)
- Add the condition so it only appears when overdue
4. Test Status-Based Routing
Scenario: Electrical test and tag equipment. You want to show “RETEST REQUIRED” only when the test has expired. Condition to show “RETEST REQUIRED”:- Add a
testStatusfield to your Tub - Set values: “current”, “expired”, “pending”
- Create “RETEST REQUIRED” Destination
- Add the condition
item.testStatus == "expired"
Using AI to Generate Conditions
For more complex conditions, use AI tools like ChatGPT to generate the expressions for you.Example Prompt Template
Example 1: Multiple Tags
Your prompt:Example 2: Date-Based with Grace Period
Your prompt:Advanced: Device-Specific Destinations
You can also show/hide Destinations based on what device someone is using.Mobile App vs Desktop Links
Scenario: You have a mobile app with deep links, but also want desktop users to access a web version. Condition for mobile app Destination:iOS Safari Workaround (SafetyCulture Example)
Scenario: SafetyCulture mobile app deep links (iauditor://) only work in Safari on iOS. You need to show the web version for iOS users in other browsers.
Destination 1: “Start Inspection (Mobile App)”
- URL:
iauditor://template/new_audit/template_id - Condition:
- Desktop users (SafetyCulture handles redirect)
- Non-iOS mobile users (Android, etc.)
- iOS users in Safari (where app links work)
- URL:
https://app.safetyculture.com/inspection/new?templateId=template_id - Condition:
Available Fields
You have access to:- Item fields -
item.name,item.status,item.tags,item.serial_number, etc. - Custom fields - Any fields you’ve defined in your Tub:
item.{yourFieldName} - Tub fields -
tub.name,tub.metadata.organizationName, etc. - Device fields -
device.isMobile,device.isIOS,device.browser, etc. - Session fields -
session.user.id,session.user.email(if logged in) - Special values -
today(current date)
Quick Device Field Reference
Device Type:device.type- Returns'mobile','tablet', or'desktop'device.isMobile- True if mobile phonedevice.isTablet- True if tabletdevice.isDesktop- True if desktop computer
device.os- Returns'ios','android','windows','macos','linux', or'unknown'device.isIOS- True if iPhone or iPaddevice.isAndroid- True if Android device
device.browser- Returns'chrome','safari','firefox','edge','opera', or'unknown'
Tips
Start simple: Test with one field and one condition first. Get comfortable before combining multiple conditions. Use descriptive field names:equipmentType is clearer than type. Future you will thank you.
Test your conditions: Create test Items with different field values to verify Destinations appear/disappear correctly.
Consider showing all instead: Before adding conditional visibility, ask: “Would showing all Destinations and letting users self-select be simpler?” Often yes.
Use URL Templates first: If you’re routing to different URLs based on Item data, URL Templates are usually simpler than conditional visibility.
When NOT to Use This
Don’t use conditional visibility for:- Different audiences seeing different content (just show all Destinations—people tap what’s relevant)
- Constructing different URLs per Item (use URL Templates instead)
- Simple scenarios (you’re probably overcomplicating)
- Completely different Destinations for different equipment types
- Warning/alert Destinations that only appear when conditions are met
- Device-specific routing (mobile app vs web)
- Complex scenarios where showing all Destinations would confuse users
Getting Help
Conditional visibility uses CEL (Common Expression Language), an industry standard. For complex conditions:- Use the prompt template above with ChatGPT, Claude, or similar AI tools
- Describe what you want in plain language—let AI translate to CEL syntax
- Test the expression with your Items before deploying widely
Related
- Using Fields - Complete field reference with all available fields
- Device Detection - Device-based routing and available device fields
- Profile Pages Overview
- Key Concepts