Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Ondeva’s Workflow engine is where your application logic comes to life. It’s built for precision automation, powerful integrations, and cross-system control—without writing backend code.
Whether you're building a startup MVP, internal tool, client portal, or enterprise process—Workflows allow you to define the logic, triggers, and data flow that make your application smart, dynamic, and autonomous.
Unlike traditional no-code automators, Ondeva workflows combine developer-grade logic (API calls, loops, branching, async execution) with a visual builder that’s designed for clarity, speed, and reuse.
Automate actions triggered by forms, button clicks, page loads, or time schedules
Read, write, transform, and delete data in your unified data layer
Call external APIs, pass and parse responses
Build modular logic using conditions, loops, and sub-workflows
You build logic visually on a drag-and-drop canvas
Each workflow consists of steps (actions) and events (triggers)
You can pass data via variables and session parameters
Every workflow is fully debuggable and testable before going live
Run AI-powered steps like text generation, keyword extraction, and audio transcription
Handle user identity, enforce licensing, and manage session-based logic
Trigger client-side actions like navigation, downloads, and analytics events
Once published, it’s available app-wide — and reusable across forms, buttons, APIs, and more
In Ondeva, workflows don’t just sit idle — they respond to events. Events define how and when a workflow starts: clicking a button, submitting a form, loading a page, or on a set schedule. You can also trigger workflows from other workflows or via custom events and exposed APIs.
Button click, file upload completed, API call and form submission events are created automatically when you select the workflow in the respective configuration of the UI component.
Other events you can create in the Workflow Builder, leave no step selected in the canvas. You’ll find the Events section.
You can assign one or multiple triggers per workflow.
Trigger:
The workflow runs when a specific button component is clicked.
How to Use:
Select the workflow in the configuration of the Button UI component.
When to Use:
Submit forms
Trigger dialogs or conditional flows from user actions
Add items to cart, save entries, start onboarding steps
Trigger:
Runs when a form component is submitted.
How to Use:
Select the workflow in the configuration of the Submit Form Button UI component.
Pair with in the workflow to extract data
When to Use:
Capture user input and persist it
Trigger follow-ups like emails or redirects
Trigger:
Fires when a specific page is loaded by the user.
Options:
Set specific pages this should apply to (or leave blank to apply globally)
When to Use:
Prefill data into components
Set session parameters
Check licenses
Trigger:
Fires on the DomReady event of a specific page loaded by the user.
Options:
Set specific pages this should apply to (or leave blank to apply globally)
When to Use:
Execute JavaScript code after a page is loaded.
Refresh UI components.
Trigger:
Executes the workflow on a scheduled basis.
Options:
Interval: every X minutes, hours, or days
Fixed Time: e.g., every day at 07:00
Specific Days: e.g., every Monday and Friday
When to Use:
Clean up stale records
Send reminder emails
Sync with third-party APIs on a schedule
Trigger:
Responds to an internal event thrown by another workflow (via step) or by the system.
Options:
Set specific pages this should apply to (or leave blank to apply globally)
Event name to listen for that other actions or the system throws
When to Use:
Decouple logic (e.g., throw user_created → handle in multiple places)
Trigger analytics or secondary flows from one action
Modularize behavior without chaining logic tightly
Execution Conditions: If you need guardrails, use session parameters and logic steps inside the workflow
Use Custom Events to keep workflows modular and loosely coupled
Be intentional with time triggers — avoid unnecessary load
The Data category is where Ondeva’s power as a backend platform comes to life. These steps allow you to load, transform, persist, and delete structured data from tables or forms. Whether your data originates from a form, API, or external file — you can capture, manipulate, and store it precisely.
Purpose:
Executes a saved query and loads its result into the session for later use in the workflow or UI.
Key Options:
Source: Choose from any prebuilt query in your project.
When to Use:
Preloading data before branching logic.
Feeding a “For Each” loop.
Populating UI components with live query results.
Purpose:
Creates or updates an entry in a database table.
Key Options:
Table: Select which table to write into.
Query: Define filters to find an existing entry (optional). If left blank, a new entry will be created. If filled only matching entries will be updated. The system will not “upsert” records.
Fields: Set which fields to update or insert, and their values (supports function editor and session variables).
When to Use:
Updating rows based on form inputs or calculations.
Storing processed data from APIs or loops.
Purpose:
Deletes a specific row from a table based on its ID.
Key Options:
Table
Entry ID: Static or calculated via formula.
When to Use:
Cleanup after user deletion or canceled transactions.
Removing outdated records via time-based workflows.
Purpose:
Creates a copy of a specific entry (row) from a table.
Key Options:
Entry ID: The original entry to copy.
When to Use:
Cloning templates (e.g., tasks, documents).
Generating reusable rows from predefined models.
Purpose:
Loads data from an external file (Excel, CSV, JSON) into the session for manipulation or saving.
Key Options:
Path: File location: You can load a file from three different sources:
an external URL
a file that was uploaded by the user and the current workflow is executed after upload completion. In that case use the variable {var_file-path}
When to Use:
Importing datasets via workflows.
Syncing data from external exports.
Processing uploaded files on form submission.
Purpose:
Manipulates user-related information such as resetting passwords, managing roles, or triggering invitations.
Key Actions:
Create user
Send invitation/reset links
Update roles (add/remove)
Generate API token
When to Use:
Onboarding flows.
Automating user role changes.
Integrating with external identity providers.
Purpose:
Extracts values from a form submitted by a user.
Key Options:
Form: The form you're targeting. The form must be present on the page and the workflow must be executed on form submit.
Variables: Map each form field to a named variable for later use.
When to Use:
Triggering workflows from form submissions.
Capturing input for condition checks, database saves, or emails.
Replacing backend form handlers with Ondeva-native logic.
Purpose:
Sets whether a form submission passes or fails validation based on custom workflow logic.
Key Options:
Can be dynamically used after Check Condition or external checks (e.g. API, duplicate check).
When to Use:
Implementing custom validations (e.g., email uniqueness, license limits).
Returning dynamic error messages to the user interface.
Combine Read Form Fields → Save Entry for complete form handling pipelines.
Use Load Query + For Each for bulk data updates.
Remember: session parameters persist across steps and allow data reuse within the same workflow.
The Presentation category in Ondeva workflows is designed to let you visually interact with users through dialogs and UI refreshes. These steps are especially useful when coordinating between user actions and front-end responses, such as showing feedback modals, refreshing components, or closing overlays.
Purpose:
Refresh components in the user interface—either within the main page or inside dialogs—so they reflect the latest data or state.
Key Options:
Ondeva’s Workflow Builder provides a visual programming interface that lets you design automations, conditional logic, and data flows without touching code — while remaining powerful enough for real-world, cross-system automation. Here's a breakdown of the UI to help you navigate with confidence.
The Workflow Builder interface is divided into four main regions:
Left Panel – Step Library
Central Canvas – Workflow Flowchart
File Type: Select the file type to load
Parsing Options: Header, sheet number (Excel), date/number format (CSV), JSON path (for nested parsing).
Component IDs: Specify which component(s) should be reloaded (e.g., tables, charts). This field references the markup id of the component(s) you want to refresh.
When to Use:
After updating data and needing to reflect it immediately on screen.
After a form is submitted and the UI must show updated totals, filters, or list items.
Purpose:
Opens a specific dialog modal to the user.
Key Options:
Dialog Dropdown: Select the dialog to display (must be predefined in your application’s UI).
When to Use:
For confirmations ("Are you sure?")
To show contextual actions or forms ("Edit user profile")
To provide feedback after a process ("Your request has been submitted")
Purpose:
Closes any currently open dialog for the user.
Options:
No configuration needed. It simply closes the currently active dialog context.
When to Use:
After a form is submitted or action completed inside a dialog
To return users to the main screen after a nested interaction
Dialogs are reusable components that can contain forms, summaries, or multi-step wizards. These steps let you orchestrate clean UI transitions between them.
The reload mechanism is context-aware, meaning only visible components are updated. Efficient for keeping UI fast and responsive.
Top Bar – Workflow Actions & Metadata
This is where you select the building blocks of your workflow. Steps are grouped into categories:
Presentation (e.g., Show Dialog)
Logic (e.g., Condition Checks, Loops)
Data (e.g., Save Entry, Load Query)
AI (e.g., Text Generation, Summarization)
(e.g., Redirect, JS Execution)
(e.g., Login, License Enforcing)
How to Use:
Drag a step from the library and drop it onto the canvas
Use the scroll or search to find specific steps
This is your primary working area where you build and connect steps in a flow.
Key Interactions:
Drag & Drop: Arrange steps freely
Connect Steps: Click the output node of a step (small circle) and drag to another to define execution order
Zoom & Pan: Use your mouse scroll to zoom and drag the background to navigate across large workflows
Right-click (coming soon): For fast actions like duplicate, delete
Structure:
Steps execute sequentially based on your visual flow
Branches (e.g., from conditions or loops) allow complex logic trees
The right-hand panel dynamically shows options for the currently selected step or global workflow settings if no step is selected.
Modes:
Step Selected: Edit fields like target table, variables, conditions, API endpoint, etc.
No Selection: Shows general workflow settings, including:
Execute via JS Function: Allows you to run this workflow from frontend components via a custom JavaScript call.
Ensure Authentication: Enforces login before the workflow can execute
This area contains core controls for saving, testing, and publishing your workflow.
Controls:
Expand: Toggles step cards between compact and detailed views
Execute: Runs the workflow immediately with current data (great for testing)
Publish: Makes the workflow live and usable throughout your app (e.g., via buttons, page triggers, time-based events)
Workflow Name: Click to rename your workflow
In the global settings panel you can define how this workflow is triggered.
Supported Event Types:
Page Load
Page Load Completed
Time Trigger (e.g., every hour, every day at 9am)
Custom Events
How to Use:
Define one or more triggers per workflow.
Button click, file upload completed and form submission events are created automatically when you select the workflow in the respective configuration of the UI component.
Use naming consistently: Label workflows clearly for reuse across your app
Modularize logic: Use sub-workflows (via "Execute Workflow") to keep flows clean
Zoom out often: Large workflows can get complex — use spacing and grouping visually
Preview values: Use session and variable names consistently to make logic traceable in debugging
Ondeva gives you real-time visibility into your workflow’s execution. Whether you're saving data, calling APIs, or processing conditions — you can simulate, inspect, and troubleshoot logic directly in the builder without deploying first.
No more blind spots. No more “why didn’t this run?”
In the Workflow Builder top bar, you’ll find the Execute button.
const showBusyIndicator = true;
const properties = {
'variable1': 'value1';
}
triggerAction('ID_OF_WORKFLOW', showBusyIndicator, properties);Executes your workflow immediately from start to finish using current session state
No trigger required — even event-based workflows can be run this way
Results and logs are shown live inside the browser console.
Each action execution is logged in the monitoring area of the platform. You can see the log for each executed workflow there. Logs are cleared after 1h.
In Call API steps:
You can store the raw response in a variable
Test runs show actual response content
Errors (e.g. bad auth, invalid body) are surfaced immediately
You can test subflows (Execute Workflow) independently
Parameters from the parent are passed through — but you can simulate local overrides
Store API results into session variables to inspect them mid-flow
Use invert condition checkboxes to test both true/false logic quickly
Use Remove Session Parameter at the start of your workflow to clear stale state
Label branches and comments using workflow step names to stay organized
Execute is for local test runs — nothing is made live
Publish makes the workflow available to triggers (form, button, time-based)
Use Execute to verify behavior before enabling triggers
If you’ll be using filters in UI components or automation, keep field names short and consistent (status, owner, is_published).
Ondeva supports table references (like foreign keys), allowing you to link entries across tables. Use them when:
Data is reused in multiple places (e.g. users, clients, roles)
You need to enforce consistency across submissions or components
But avoid excessive normalization for operational or analytical data. For example:
If you're tracking tasks, log entries, or user actions — and frequently need to group, sort, or filter by related values — it’s often better to keep those fields in the same table.
“One-to-one” or “many-to-one” relationships where a dropdown picker makes UX cleaner
Data that’s maintained separately (e.g. Teams, Plans, Categories)
Metrics, submissions, or logs you’ll run analytics on
Dynamic data where query speed matters more than data purity
Avoid deep reference chains — they create overhead and slow down performance in large apps.
For profile-like data (user preferences, application forms, onboarding data), enable the One Entry Per User setting:
Prevents duplicate submissions
Simplifies queries and access control
Automatically ties data to the logged-in user
Use fields like status, phase, or is_active to represent the state of your entries. These fields allow:
Workflows to branch based on state
UI to show dynamic labels or badges
Queries to filter logically (e.g. “only active”, “only pending approval”)
For operational tables (e.g. task tracking, logs, form submissions), set defaults to:
Reduce user input friction
Ensure consistency across manual and automated inserts
Prevent missing or inconsistent data downstream
Example: Set default status = pending, priority = normal, or country = DE.
Field-level validation prevents fragile downstream logic. Use:
Required fields to avoid nulls
Regex to ensure structure (e.g. emails, phone numbers)
Unique per user for IDs, usernames, emails
Formula validations for business rules (e.g. start_date < end_date)
Ondeva supports complex logic — but don’t overuse Text fields to store structured blobs. Instead:
Use rich text for formatted content
Use JSON-compatible structures only when paired with processing logic in workflows
For audit trails or analytics, add fields like:
created_at (date)
created_by (user reference)
last_updated (date)
is_deleted (soft delete flag)
These can power:
Admin interfaces
Time-based automations
Conditional access to data
Strong data modeling leads to strong apps. When building with Ondeva:
Keep schemas clean, normalized, and queryable
Use built-in settings to simplify access control and validation
Combine structured tables with workflows to build powerful, self-sustaining systems
Tables aren’t just storage — they’re the living logic of your app.
Ondeva’s Custom Tables area is split into two functional tabs — Structure and Data — both accessible from within the Data section of the platform. The UI is designed to help you move fluidly between modeling data and interacting with live entries.
This overview breaks down how the user interface works specifically when working with a table in Ondeva.
To access your custom tables:
Click the Data icon in the left-hand navigation.
Select a table from the list — or create a new one.
Once selected, the table editor opens with two tabs:
Structure
Data
The Structure tab is where you define the schema (fields/columns) of your table.
Center panel: Displays the list of fields currently in the table (columns). Each field shows:
Field label
Data type
Identifying column indicator (if applicable)
The Data tab lets you view and manipulate actual entries (rows) inside the table.
Top bar:
Add Entry button
Export to CSV button
Center panel (Table View):
Autosave: Changes in both Structure and Data tabs are saved instantly — there’s no Save button.
Validation Feedback: Required fields and invalid entries are flagged in real time in both field settings and data entry.
Drag & Drop Support (Structure Tab):
Reorder fields by dragging them in the list.
Ondeva’s custom table UI is optimized for live, real-world development:
Two powerful tabs (Structure + Data)
Clear side-by-side editing
No-code field config with real-time validation
Whether you're defining schemas or running operations, the interface keeps you focused and fast.
Ondeva workflows use two types of runtime values to hold and pass data: Session Parameters and Workflow Variables. These are critical for making workflows dynamic, data-driven, and responsive to user inputs or external API responses.
Purpose:
Creates or updates key-value pairs that persist across the user’s entire session.
Key Options:
Parameter Name: Any label (e.g., user_id, submission_status)
Value: Can be static, calculated (via function editor), or fetched from previous workflow steps
Scope & Availability:
Session-wide: Available in all workflows, queries, and UI conditions
Reference format: {parameters_parameterName}
Use Cases:
Store user or environment state (e.g., {parameters_isAdmin})
Control conditional UI logic (e.g., show/hide components)
Pass session state into queries or Save Entry steps
Purpose:
Deletes an existing session parameter.
Key Options:
Choose from a list of parameters
Use Cases:
Cleanup state after a critical branch completes
Remove sensitive data from session memory
Purpose:
Creates a local variable that exists only for the current workflow run.
Key Options:
Variable Name: Identifier (e.g., user_email, apiResponse)
Value: Set via static input or dynamic expressions (function editor)
Scope & Availability:
Available only in:
The current workflow
Any sub-workflows triggered from this one
Any queries loaded within this workflow
Use Cases:
Store API responses for use in the same flow
Handle intermediate values like counters or temporary results
Pass values into Save Entry, API, or condition checks
Purpose:
Constructs a structured object in JSON and stores it as a variable.
Key Options:
Definition: Use the editor to build a JSON object
Target Variable: Define where the object will be stored
Use Cases:
Build a request payload before calling an API
Create a multi-field object to pass into a save or update step
Package data to hand off to a sub-workflow
You can use parameters and variables almost anywhere in Ondeva workflows — in inputs, field mappings, conditions, and even API bodies.
Variable: {var_variableName}
Parameter: {parameters_parameterName}
All Workflow Inputs: Including Save Entry, Call API, Check Condition, Send Email, etc.
All Queries: When loaded via workflow, queries can reference workflow variables and session parameters.
Design Conditions: Visibility, enable/disable logic for UI components (parameters only).
Use variables for scoped values that don’t need to persist (API result, loop index, form temp values).
Use session parameters to drive cross-workflow logic and UI behavior (permissions, active user state).
Clean up unused parameters to avoid polluting the session state.
Each field (column) in an Ondeva table defines the type of data it stores, the validation rules it follows, and how it's presented in both backend and frontend contexts.
Below is a reference of all supported field types and their configuration options.
Most field types include:
Field Name (Label): Required for all fields.
Identifying Column toggle: Used for display in dropdowns/reference pickers.
Required: User must provide this field in forms.
Default Value: Applied to new entries unless overwritten.
Single-line input for strings.
Options: default value
Validation: regex, length, uniqueness.
Integer-only numeric input.
Options: default value
Validation: min, max, uniqueness, regex, formula-based.
Allows decimal numbers (e.g. 3.14, 19.99).
Options: default value
Same validations as Number.
Formatted text (HTML-friendly).
Used for long content fields, email templates, etc.
Same validations as Text
Stores a date (with optional time).
Options: Include time toggle, Default date picker
Boolean value (true/false).
Options: Default checked state
Single select from predefined options.
Options: Choices list, Default selection
Multi-select dropdown (returns array).
Same options as Dropdown.
Upload and store a single file.
Option: Max file size, File type restrictions
Stores multiple files (advanced component).
No direct backend data entry (used via front-end components).
Same options as File
Points to another table's entry (foreign key).
Options: Default referenced entry, Restrict selectable entries
Stores a reference to an internal page in your app (useful for redirections).
Reference one or more roles to this entry.
Used for permissioning or UI personalization.
Stores geolocation metadata:
Address
Latitude / Longitude
Region
For storing geo boundaries, polygons, zones.
No additional config
Write-only field, encrypted.
The content of this field is encrypted not hashed. DON'T use this field for sensitive passwords. A possible use case can be temporary tokens.
Auto-incrementing, uneditable ID.
Used for internal tracking or display.
No configuration options.
Ondeva supports multiple validation types:
Required User must provide a value before saving.
Default Value Auto-fills this value on new entries.
Maximum / Minimum For numbers or string lengths.
Regex (Regular Expressions) Pattern matching for input (e.g., emails, postal codes).
The Logic category enables decision-making, control flow, and integration within workflows. These steps are used to create dynamic, reactive applications that can branch, loop, or integrate with external systems — without writing a single line of backend code.
Purpose:
Evaluates one or more conditions and executes different branches of the workflow based on the result (true or false).
Key Options:
Logic Operator: AND / OR — controls how multiple conditions are combined.
Conditions: Define comparisons using left-hand value, operator, and right-hand value (e.g., user.age > 18).
Invert Result: Flips the result of the condition (true becomes false, and vice versa).
Outputs:
Two required outputs: one for the true branch, one for the false branch.
When to Use:
Gate logic based on user roles, values in a form, or backend response.
Control what happens next depending on whether conditions are met.
Purpose:
Calls another existing workflow (sub-workflow), allowing you to modularize logic and reuse workflows.
Key Options:
Workflow Selector: Choose any existing workflow from your app.
When to Use:
To reduce repetition by reusing logic across workflows.
When creating a "parent" workflow that delegates subtasks.
For clean separation of logic (e.g., “Send email”, “Log event”, “Sync CRM”).
Purpose:
Loops over a list (table, array, query result) and executes a workflow for each item.
Key Options:
Workflow: The workflow to execute for each item.
Variable: The list or table to iterate through.
Async Mode: When enabled, Ondeva will process the items in a separate thread / task. Therefore not blocking the user interface and allow the user to continue navigating.
Optional Enhancements:
After Completion: Dialog to show after all iterations complete.
Progress Dialog: Dialog to show to the user during async execution. When creating a custom progress dialog you have to mark the places for the progress information with these CSS classes: progress-current for the current progress value and progress-total for the total amount of items.
When to Use:
Batch-update rows in a table.
Call external APIs for multiple records.
Send personalized emails to a filtered group.
Purpose:
Connects to external services by calling any HTTP endpoint and stores the response in session variables.
Key Options:
Endpoint URL: The target URL of the API.
Method: GET, POST, PUT, DELETE, etc.
Auth Profile: Preconfigured authentication (OAuth, token, etc.).
Optional Enhancements:
Headers: Custom headers (optional).
When to Use:
Integrating with third-party tools (CRMs, payment systems, external DBs).
Sending dynamic data from Ondeva to another system.
Consuming REST APIs without needing backend code.
Keep steps modular: Use “Execute Workflow” to isolate logic and improve readability.
Use session variables to pass state between condition checks and API calls.
Always handle error cases, especially for external API calls (e.g., use condition checks on HTTP response codes).
In Ondeva, tables define your application's data model. Think of them as the backbone of your backend — every form, automation, query, or dashboard ultimately connects to data that lives here.
The Table Structure view is where you define fields, their types, validations, and behavior. It's also where you configure table-level settings like per-user limits or identifying columns. Ondeva ensures changes are saved instantly, so structure editing is frictionless and production-safe.
To edit a table:
Navigate to the Data tab from the left sidebar.
Select a table from the list (or create a new one).
You'll be taken directly to the Structure tab — the schema editor for your table.
Here, you'll define columns, choose their types, configure field properties, and manage table-level settings.
Clicking on an empty space in the Structure view reveals general settings for the table in the right-hand panel.
Table Name Editable directly from the top title bar. The name is persisted across all references (queries, workflows, API exposure).
One Entry Per User When enabled, this restricts each frontend user to a single entry in the table. Ideal for profiles, preferences, or single submissions.
Each table is composed of (columns). You can:
Add fields with the "+" button
Rename by clicking the label
Reorder by drag-and-drop
Remove fields via the trash icon
Fields can also be marked as:
Identifying Column: This becomes the default display label across UI components, dropdowns, and table references.
The Table Structure area in Ondeva gives you full control over your data model with:
Instant updates
Developer-grade validations
A wide range of input types
Full support for relationships, geodata, and advanced field logic
Whether you're modeling a CRM, form backend, analytics dashboard, or a marketplace database, your table starts here.
Ondeva gives you precise control over user access, session behavior, and monetization flows. These steps are essential for any SaaS or productized app built on Ondeva — enabling authentication, license enforcement, and seamless e-commerce actions from within workflows.
Purpose:
Forces the user to authenticate. If already logged out, they’ll be redirected to the login page and returned to their current screen upon success.
When to Use:
Top bar: Shows the current table name. Click it to rename the table inline.
Right-hand panel: When a field is selected, this panel displays field-specific settings:
Field name
Data type
Validation rules
Default values
Required toggle
Custom logic (varies by field type)
Floating actions:
Add Field: Button at the bottom of the field list
Delete Field: Trash icon appears when hovering over a field
Empty canvas click: Clicking in an empty space reveals Table Settings.
Spreadsheet-style table with one row per entry
Each column matches a field from your structure
Checkboxes to select rows for deletion
Right-hand panel (Entry Editor): When a row is selected:
Shows all fields and values for that row
Supports inline editing per field type
Autosaves all changes instantly
Pagination Navigation: Shown at the bottom once entries exceed 20 rows. Navigate pages to view more data.
The order is reflected in Data view and UI components.
Persistent Context: Switching between tabs (Structure ↔ Data) retains your selected table and open row/field.
Country
Validations: action, regex, formula, unique
Unique (global or per user) Ensures no duplicates in this column.
Formula-Based Validation Define logic expressions that must evaluate true.
Action-Based Validation Delegate validation to a separate workflow or script for complex checks.
Content Type: Defines the body format (application/json, etc.).
Body: Raw JSON body sent with the request. If the request method allows for a payload.
Response Handling:
If Text: Store in a session variable.
If File: Save the response to a specified table field.
Guard protected content
Require login before form submission
Secure workflows that write to user-specific data
Purpose:
Checks whether the user has a valid license (or set of licenses). If the check fails, the user is blocked from progressing.
Key Options:
License Selection: Choose one or more required licenses
When to Use:
Gate workflows or features based on paid plan
Handle upsells for premium components
Limit access to internal tools or downloads
Purpose:
Adds a product or license to the current user’s shopping cart.
Key Options:
Product / License: Select the item to be added
Clear Cart First: Optional — clears the current cart before adding the new item
When to Use:
Trigger a checkout flow (e.g. “Buy Now” button)
Offer upgrade paths (add license for additional features)
Support dynamic pricing tiers or modular subscriptions
Purpose:
Logs a session-level tracking entry with optional metadata for analysis. The Session ID is stored in a variable: {var_sessionId}
Key Options:
User ID (optional)
Session ID (optional)
URL (context page)
When to Use:
Record usage sessions for metrics
Tie workflows to performance data
Build your own internal analytics pipeline
Purpose:
Tracks a page visit for the current session and user. The Visit ID is stored in a variable: {var_visitId}
Fields:
User ID (optional)
Session ID (optional)
URL (context page)
When to Use:
Funnel tracking
Custom conversion attribution
Heatmap or flow visualization features
Combine License Enforcing with Design Visibility rules for a seamless UX.
Use Add to Cart in pricing tables, modals, or gated content dialogs.
Log sessions and page views if you want to collect analytics event from other sources then the automatic tracking of Ondeva’s analytics system.
Ondeva integrates AI directly into your workflows — allowing you to generate, extract, and analyze data using Large Language Models (LLMs) without needing to wire up external services. AI becomes just another building block in your application logic, enabling personalized automation, rich content generation, and powerful classification.
All AI steps store their results in session variables or table entries, making them immediately usable in downstream logic, queries, and UI components.
Purpose:
Generates AI-powered text from a prompt and stores the result in a session variable.
Key Options:
Prompt: The input text, question, or command given to the model (can include dynamic variables)
Variable: Name of the variable to store the result
When to Use:
Generate product descriptions or summaries
Rephrase or complete user input
Dynamically fill message templates or notification content
Purpose:
Generates an image based on a prompt and saves it into a specific field in a table entry.
Key Options:
Prompt: Describes what the AI should generate
Target Table, Entry ID, Field: Where to store the resulting image
When to Use:
Automatically generate hero or thumbnail images for new content
Create profile avatars or decorative assets from user prompts
Purpose:
Extracts keywords from a text prompt and stores them as an array of strings in a variable.
Key Options:
Prompt: Text to analyze (e.g., a blog post or support ticket)
Variable: Where the array of keywords will be saved
When to Use:
Tag content for search or filtering
Analyze sentiment topics in support logs or survey data
Purpose:
Condenses a long input text into a shorter, coherent summary.
Key Options:
Prompt: The original long-form text
Variable: Where the summary is stored
When to Use:
Summarize meeting notes, emails, or documentation
Offer TL;DR versions of user-generated content
Purpose:
Transcribes an audio file into plain text using AI.
Key Options:
Variable: Name of the session variable holding the audio input
Target Table / Entry / Field: Where to store the transcription result
When to Use:
Process voice submissions (e.g., customer feedback, voice forms)
Extract speech from uploaded interviews or podcast clips
AI prompts support full use of {parameters_x} and {var_x} references, allowing you to dynamically personalize inputs per user/session.
Results can be directly used in downstream steps like Save Entry or Send Mail.
Use Text to Variable before API calls or UI rendering to dynamically generate values based on live context.
Reference format: {var_variableName}
Sub-Workflows: Inherit all variables from the parent workflow.
Javascript code: You can access variables and parameters when executing JavaScript code through the “Code” step of a workflow. All variables and parameters are available through the individee.meta object.
Use in Queries
✅
✅ (when triggered by workflow)
Best For
Shared session state
Internal calculations & short-term data
Scope
Global (across all workflows & UI)
Local (within current + sub workflows)
Lifetime
Until manually removed or logout
Until workflow finishes execution
Syntax
{parameters_someName}
{var_someName}
Use in UI Logic
✅ (visibility/enabled conditions)
❌
console.log(individee.meta.paramters['var_variableName'];These steps are designed to control the user’s experience directly — whether that means navigating between pages, triggering downloads, injecting JS, or throwing custom events inside your frontend. Together, they let you seamlessly blend logic with UI behavior.
Purpose:
Redirects the user to another page — either internal (within the app) or external.
Key Options:
Internal Link: Dropdown of your app’s defined pages
Custom URL: External or dynamically built URL (can use {parameters_} or {var_} references)
Parameters: Add query parameters to internal links
Open in New Tab: Optional checkbox for opening internal or external links in a new tab.
When to Use:
Redirect user after form submission or login
Navigate based on user selection or logic (e.g., "Go to dashboard if logged in")
Link into third-party tools or portals
Purpose:
Runs a block of custom JavaScript in the user’s browser.
Key Options:
Code Editor: Paste your JS snippet
Timeout (ms): Execution timeout (prevents runaway scripts)
When to Use:
Extend the possibilities of Ondeva with custom code that consumes variables and data collected via Ondeva.
Modify client-side DOM manually
Call browser APIs (clipboard, localStorage, etc.)
Best Practices:
Keep scripts short and well-scoped. Don’t overload the client with unnecessary scripts.
Use try/catch inside your script if needed
Use the data provided by the individee.meta object safely. You have access to the variables and parameters individee.meta.parameters as well as to loaded queries individee.meta.tables .
Purpose:
Initiates a file or visual component download for the user.
Modes Supported:
Chart Snapshot: Download an image of a chart component on the current page. Pass the markup id of the chart component.
Map Snapshot: Download an image of a map on the current page. Pass the markup id of the map component.
File Field of Table Entry: Downloads a file stored in a specific field in a table
Generated Document: PDF or spreadsheet generated by Ondeva’s document engine
Key Options:
Component or Table Reference: Depending on the mode
Filename: Set static or dynamic file names
When to Use:
Export reports or dashboards
Let users download file attachments (e.g., invoices, submissions)
Offer dynamic content based on data or session state
Purpose:
Fires a custom event into Ondeva’s event system — useful for analytics, real-time responses, or syncing across components.
Key Options:
Event Name: Unique identifier (e.g., user_registered, plan_upgraded)
Persist Event: When checked, the event is stored for analysis in the performance area
Metadata: Optional values like session ID, user ID, or URL context
When to Use:
Custom instrumentation (track clicks, conversions, form usage)
Fire off workflows based on frontend actions (when listening via another workflow)
Log milestones for performance dashboards
Use named events consistently to track workflows (e.g., invoice_paid, support_request_opened)
Always set a fallback for Go to URL when depending on variables (avoid broken redirects)
Leverage download triggers for user-facing confirmations or exports, especially in enterprise tools
Ondeva's Table Data interface lets you view, create, edit, and manage the actual records that live in your app’s backend — directly inside your browser. It’s a fast, developer-friendly interface designed for real-world teams building products, internal tools, or complex workflows.
Whether you’re running a CRM, building a marketplace, collecting form submissions, or managing operational datasets, this view gives you full control over your live application data — no SQL required.
From this screen, you can:
Create and update entries inline
Upload files or toggle values instantly
Export everything to CSV
Navigate large datasets with pagination
Inspect every field type, exactly as it behaves in production
Open the Data section from the left sidebar.
Select a table.
Switch to the Data tab at the top of the screen.
The interface displays your data in a spreadsheet-style view — every row is an entry, and every column reflects a field from your table schema.
Click any row to open its full details in the right-side editor. You’ll see all fields (columns), editable based on their data type.
Common editing behaviors:
Text / Number: Type directly
Date: Select from a date picker
Checkbox: Toggle with one click
Dropdown / Multi-Select: Choose from options
Changes are automatically saved.
Click the “Add Entry” button to open a blank record. Fill in fields — any default values (if configured) will be pre-filled — and your changes are saved as you go.
Select any row
Click the trash icon
Confirm deletion in the dialog
Note: Deletes are permanent. For reversible workflows, consider adding a “status” or “archived” field instead.
Ondeva automatically paginates tables to maintain performance. Each page shows 20 entries by default. Use the navigation controls at the bottom to move through your dataset.
Click the “Export to CSV” button to download the full table contents in .csv format.
The export includes:
Every field (column)
One row per entry
Raw values, suitable for spreadsheets, databases, or analytics tools
Ondeva’s workflow engine lets you work with data programmatically:
Load Query to retrieve matching entries
Save Entry to add or update entries
Delete Entry, Duplicate Entry, For Each, and more
This is especially useful for:
Automating form submissions
Importing files
Syncing external systems
Updating many rows at once
Learn more in the chapter.
The Data view gives you hands-on access to the heart of your application: its live records.
With fast editing, file support, and CSV export built-in, it’s perfect for:
Testing and verifying backend behavior
Managing operations workflows
Editing production data with confidence
No database admin panel needed. Just click, edit, and move fast.
File: Upload or replace files inline
Rich Text: Edit via a rich input (viewed as plain text here)
File Manager
Not editable here (UI-only)
Table Reference
Select another entry
Location
Edit address and geodata
Password
Write-only, hidden
Rich Text
Text only (no formatting)
GeoJSON
Not editable in backend UI
Text / Number
Inline editable
Date
Opens a calendar picker
Checkbox
Toggle on/off instantly
Dropdown
Select single value
Multiple Choice
Select multiple values
File
Upload & replace