Project Editor

The Project Editor is the primary development environment for an ioLoop Project. It is where you build, configure, test, publish, and continue improving the application represented by the Project.

You open the Project Editor from the Account Dashboard by selecting a Project you own or one shared with you. The editor organizes the application's frontend, backend, AI capabilities, integrations, resources, settings, and publishing controls within a single workspace.

You can build visually, create application logic with Page Flow and Cloud Flow, customize functionality with JavaScript and CSS, and use AI Wiz to help create or modify Project components. These approaches work together, so you can choose the one that best suits each task.

Project Editor Sections

The Project Editor menu provides access to seven main areas:

• Frontend — Build and manage the user-facing experience through Pages & Forms, Media, and Code.
• Backend — Manage the Project's Database and Cloud Flow server-side logic.
• AI Agents — Create AI Agents and configure their instructions, knowledge sources, and capabilities.
• Integrations — Configure Connections to external services, APIs, credentials, and supported tools.
• Scale — Review and manage available Project capacity and runtime resources.
• Settings — Configure Project Settings, Users, User Groups, and Checkpoints.
• Publish — Publish the application and launch its published version.

Although these areas are organized separately in the editor, they are parts of the same application. A page can collect information, Page Flow can handle user interactions, Cloud Flow can enforce business rules, the Database can store records, and Connections or AI Agents can provide additional capabilities.

Working in the Project Editor

You can move between Project areas as you build. There is no requirement to complete the frontend before creating database tables, or to finish the backend before adding an integration. Work on individual components as needed, then test how they interact.

Create and modify components

Use AI Wiz to describe features or changes in natural language and have it help build or modify the corresponding Project components. You can also work directly in the editor to create pages, configure data, define workflows, and adjust settings.

For application logic, Page Flow and Cloud Flow both support visual programming blocks and JavaScript code blocks, including combinations of the two within the same flow. For frontend customization, JavaScript and CSS assets provide additional control.

You can revisit components created with AI Wiz and modify them through the editor, or return to AI Wiz to help refine your work.

Test and refine your work

Test components as you develop them rather than waiting until the entire application is complete. For example, you can check page interactions and form validation, verify database operations, exercise Cloud Flow workflows, and evaluate integrations and AI Agents.

When testing workflows that use external services or modify data, consider whether those actions could have effects beyond the immediate test. Checkpoints, available under Settings, help you manage saved points in Project development.

Changes made during development do not automatically update the published application. You decide when to publish an updated version.

Frontend

The Frontend area contains the parts of the Project that shape what users see and interact with.

Use Pages & Forms to create pages, forms, and user interfaces. Pages can include visual layouts, page-specific settings, access rules, and Page Flow logic for client-side behavior.

Use Media to manage images and other public assets used by your pages and Project experience.

Use Code to manage JavaScript and CSS assets. These assets support reusable frontend behavior, custom styling, and specialized interface functionality while remaining organized within the Project.

Frontend Implementation Model

Frontend implementation generally combines three layers:

• Page structure and design: The visual layout, page type, form elements, metadata, URL settings, and access configuration.
• Page Flow: Client-side logic associated with a page. It can respond to user actions, validate input, call supported ioLoop APIs, work with data, display messages, and coordinate page behavior. Page Flow supports visual programming blocks and JavaScript code blocks within the same flow.
• Code assets: Reusable JavaScript and CSS files that can be included on individual pages or across the Project.

A simple page might need only visual configuration. An interactive page can use Page Flow to respond to events and coordinate browser-side behavior. More advanced interfaces can incorporate JavaScript and CSS assets for reusable or specialized functionality.

Use Page Flow for browser-side interaction and presentation logic. When an operation requires protected credentials, centrally enforced business rules, or execution independent of the browser, use Cloud Flow through a supported interface instead.

Backend

The Backend area contains the data and server-side logic that power your application.

Use Database to define and manage Project tables, fields, queries, and access rules. The Database stores structured information used by pages, forms, Cloud Flow, AI Agents, and supported APIs.

Use Cloud Flow to implement server-side workflows. Cloud Flow can process data, enforce business rules, expose webhooks, run background tasks and agentic loops, work with files, call external services, and coordinate backend automation.

Backend Implementation Model

The backend combines persistent application data with server-side execution.

The Database defines the Project's structured data model. Tables hold records, fields define their structure, queries support data retrieval, and access rules control permitted operations through supported runtime interfaces.

Cloud Flow implements logic that should run on the server. It is appropriate for operations involving protected credentials, centralized validation or authorization, external services, incoming webhooks, or tasks that need to run without an active browser session.

Like Page Flow, Cloud Flow supports visual programming blocks and JavaScript code blocks, which can be combined within the same workflow.

The two flow systems serve different purposes:

• Page Flow executes in the browser and coordinates page-level interactions and client-side behavior.
• Cloud Flow executes on the server and coordinates backend processing and trusted application behavior.

For example, Page Flow can validate a form and initiate a supported backend request. Cloud Flow can then enforce server-side rules, update the Database, and invoke an external service without exposing sensitive credentials to the browser.

AI Agents

The AI Agents area lets you build intelligent capabilities into your application.

An AI Agent can be configured with instructions, behavior, and knowledge sources. Depending on its configuration, it can work with Project data, invoke functions, use supported Connections, and participate in application workflows.

AI Agents are different from AI Wiz. AI Wiz assists you in developing the Project. AI Agents are capabilities you create within the Project for application users or automated workflows.

AI Agent Implementation Model

AI Agents use Knowledge Sources to access Project-specific information and capabilities rather than relying solely on general model knowledge.

Two important knowledge source patterns are:

• Table Knowledge Sources: Provide controlled access to Project database tables.
• Function Knowledge Sources: Expose custom Project functionality through functions implemented with Cloud Flow.

Supported Connections and other knowledge source types can extend what an agent can retrieve or do. AI Agents can also participate in backend workflows, including Cloud Flow webhooks, background tasks, and agentic loops.

Because an agent may retrieve data or initiate actions, distinguish who is permitted to use the agent from what the agent is permitted to access or execute. Configure the relevant access rules and enforce authorization in the underlying data operations and server-side functions as appropriate.

Integrations

The Integrations area connects your Project with external services and APIs.

Use Connections to configure service access, API credentials, reusable API calls, and supported third-party integrations. Connections keep external service configuration organized instead of scattering it across application code.

Depending on the connection type and the Project's design, integration functionality can be used by Cloud Flow, AI Agents, and supported frontend workflows.

Integration Implementation Model

A Connection represents a managed relationship with an external service. It may provide credentials, configured API operations, account-level service access, or other supported integration functionality.

When an integration requires sensitive credentials or privileged operations, Cloud Flow provides a server-side place to execute the corresponding logic. AI Agents can also access supported integrations through Knowledge Sources or function-backed behavior.

A frontend page can initiate an operation that uses a Connection, but sensitive credentials and privileged service operations should remain behind appropriately controlled server-side interfaces. Avoid embedding secrets directly in page scripts or other browser-accessible assets.

Scale

The Scale area is where you review and manage the Project resources and capacity available to support its runtime needs.

As an application grows, increased usage or more demanding workloads may require additional resources. Scale provides the Project-level controls for reviewing and adjusting supported capacity options, subject to the resources and limits available under your plan.

Scale is concerned with the resources used to run the application rather than the pages, data model, or workflows that define its behavior. Use it alongside application testing and performance evaluation when deciding whether resource changes are needed.

Settings

The Settings area manages Project-wide configuration, application users, access organization, and development checkpoints.

• Project Settings: Configure application-level options such as the starting page, published URL, branding, fonts, global styling, included code assets, and other supported defaults.
• Users: Manage the people who can sign in to the application built from the Project.
• User Groups: Organize application users and configure access to supported pages, data, and other resources.
• Checkpoints: Manage saved points in Project development.

Project-wide settings can affect multiple parts of the application. For example, a change to global styling or an included code asset may affect several pages, while changes to user and group configuration may affect access throughout the application.

Project Users vs. Account Creators

Account Creators collaborate on building and managing Projects through the Account Dashboard and Project Editor. Their Project access is controlled by the Creator permissions assigned to them.

Project Users are the people who sign in to the application created by the Project. They belong to the application's runtime user model and can be organized into User Groups.

These are separate permission systems: Creator permissions govern who can work on the Project, while Project Users and User Groups help govern who can access and use the application. For account-level collaboration, see Creators. For application identities and membership, see Users and User Groups.

Publish

The Publish area provides the controls for making the application available to its intended users and releasing subsequent updates.

• Publish Project updates the published application with the Project's current development state.
• Launch Project opens the published application through its configured URL so you can review the live experience.

Launching does not publish pending changes. Use Publish Project to release changes, then Launch Project to verify the published application.

Development and Published Environments

ioLoop separates ongoing development in the Project Editor from the application accessed by users through its published URL.

You can revise pages, modify Page Flow or Cloud Flow logic, adjust settings, and test new functionality without automatically changing the published version. When those changes are ready, use Publish Project to update the published application.

Application code and configuration are not the only considerations. Depending on the Project's configuration, development and published execution may use different data resources or runtime contexts. When testing and publishing, verify which environment an operation affects rather than assuming that development test records and published application data are interchangeable.

Publishing changes and managing application runtime availability are also separate concerns. For example, powering a Project on does not itself republish the application. For the relevant account-level controls, see My Projects.

Working with Permissions

Your available actions in the Project Editor depend on whether you own the Project or have been granted access by its owning account.

For Creators with Project-level access, the documented permissions are:

• Viewer: Read-only access to the Project.
• Contributor: Read and write access to the Project.
• Publisher: Read, write, and publish access to the Project.

An account-wide Publisher can have Publisher access across all Projects belonging to the account, without automatically receiving account-administration privileges.

These Creator permissions are different from the runtime permissions configured for Project Users and User Groups. For details, see Creators and Shared with Me.

How Project Areas Work Together

Consider an internal approval application in which employees submit requests and managers review them:

1. Pages & Forms provides the request form and approval interface. Page Flow validates user input and coordinates browser-side interactions.
2. Cloud Flow performs server-side validation and applies approval rules. The Database stores requests, their statuses, and approval history.
3. Connections enable a Cloud Flow workflow to notify the appropriate reviewer through an external service.
4. Users and User Groups define which application users can submit requests, view them, or perform approval actions, with corresponding authorization checks in the application logic.
5. AI Agents, if needed, can summarize requests or help users retrieve information through configured Knowledge Sources and permitted functions.
6. Publish Project releases the application or its updates. Launch Project opens the published experience for verification.

This example shows how editor components work together: the frontend handles interaction, the backend enforces application behavior, Integrations and AI Agents extend functionality, and Settings and Publish control access and release.

Where to Go Next

If you are new to the Project Editor, Frontend is a good place to start building the user experience, followed by Backend when your application needs structured data or server-side logic.

Explore AI Agents and Integrations as you add intelligent behavior or external services. Use Settings to configure Project-wide behavior and access, Scale to review runtime resources, and Publish when you are ready to release and verify the application.

You can return to any area as requirements change. The Project Editor is intended to support an ongoing cycle of building, testing, refining, and publishing within the same Project.