# Product model

As the site owner, you operate one JustFlows installation. Your customers create workspaces inside it. Each workspace keeps its own members, flows, connections, AI accounts, agents, prompts, skills, knowledge bases, MCP servers, approvals, usage, and subscription.

A flow becomes runnable when it has a valid trigger, connected nodes, any required workspace credentials, and a published version. Editing a draft does not silently change the currently published version.

# Site-owner responsibilities

• Host the application securely and keep its code, database, dependencies, and TLS certificate current.
• Keep the scheduler and production queue worker running.
• Configure mail, storage, WebSockets, global OAuth applications, AI defaults, billing, and plan entitlements.
• Monitor system health, workflow failures, AI usage, storage, queues, subscriptions, and application logs.
• Publish suitable legal pages and establish data retention, acceptable-use, and privacy policies for your market.
• Provide customer support for the instance and its workspace configuration.

Check the production server before uploading the package. The web installer verifies the PHP requirements, but the scheduler, worker, HTTPS, and outbound connectivity are operational requirements you must arrange separately.

Small installations can start with the database queue and local storage. Redis and remote object storage are better fits when traffic, concurrent runs, or uploaded knowledge sources grow.

# Files setup

1. Download the product archive from your Envato downloads.
2. Upload the archive to the directory that will contain the application and extract it on the server. Extracting server-side helps prevent hidden files from being skipped.
3. Copy the contents of the package's Script directory into the application directory.
4. Confirm that hidden files such as .env and .htaccess are present.
5. Allow the web server user to write to storage/ and bootstrap/cache/. Do not make the entire application publicly writable.

# Document root Important

Configure the domain's document root to point to the package's public/ directory. For example, if the application lives in /var/www/justflows, the public document root is /var/www/justflows/public.

This keeps .env, application code, logs, and stored secrets outside the public web directory. If /public appears in your site URL, the document root is not configured correctly.

Web server notes

• Apache/LiteSpeed: allow the included .htaccess rules and enable URL rewriting.
• Nginx: route requests through public/index.php using a standard Laravel virtual host.
• Reverse proxies: forward the original host, scheme, and client IP headers, and ensure the application recognizes HTTPS.

# Database setup

1. Create an empty MySQL or MariaDB database using utf8mb4.
2. Create a dedicated database user with a strong password.
3. Grant that user the privileges needed to create and alter tables and to read and write application data.
4. Record the host, port, database name, username, and password for the installer.

Do not reuse the database administrator account. In managed database services, also allow network access from the application and worker hosts.

# Web installer

Visit https://your-domain.example/install. The installer guides you through:

1. Requirements: PHP 8.2 and the required PHP extensions.
2. Database: connection details for the empty database.
3. Site and owner: site name, canonical URL, administrator account, and Envato purchase code.

After the installer completes, sign in at https://your-domain.example/admin. The install lock in storage/app/installed prevents the installer from running again.

Complete these items in order before inviting customers. Several features depend on earlier services, so testing them as one chain is more useful than checking individual settings in isolation.

The settings pages are grouped under Admin → Settings. Configure the platform services first; customers then add workspace-specific credentials and flows from the main application.

# Site, branding, and localization

Start in Admin → Settings → General:

• Site: name, canonical App URL, description, slogan, email verification, and registration onboarding.
• Branding: light and dark logos, favicon, social-sharing image, and login background.
• Appearance: theme switching, default theme, text direction, and page transitions.
• Localization: default language, language switcher, browser-language detection, and timezone.
• Homepage: public homepage behavior and post-registration redirect.
• Notifications: contact email and optional web push/VAPID keys.

Generate the customer-facing color theme in Admin → Settings → Colors. Keep sufficient contrast between the primary/gradient colors and text. Configure admin-specific logos and title under Admin → Settings → Admin.

# Transactional email

Open Admin → Settings → Emails. Email is used for verification, password resets, team invitations, 2FA, approvals, billing notices, trials, and operational notifications.

Use a domain-authenticated sender and configure SPF, DKIM, and DMARC with your mail provider. The separate Trial Emails tab controls branding and copy for trial and subscription lifecycle messages.

# Scheduler

Add one cron entry that runs Laravel's scheduler every minute:

* * * * * cd /path/to/justflows && php artisan schedule:run >> /dev/null 2>&1

Use absolute paths if the hosting environment has multiple PHP versions. The scheduler drives:

• health heartbeat and housekeeping;
• Gmail, Outlook, and scheduled workflow trigger polling;
• resuming workflows after wait nodes;
• workflow-state and Flowy-history retention;
• trial and subscription expiry/notification processing;
• eligible account deletions and the daily sitemap.

# Runtime, cache, sessions, and queues

Open Admin → Settings → Runtime.

Sessions

Choose file, database, or Redis storage. Changing the session driver may sign out active users. Redis is appropriate for multiple web servers; file sessions are simplest for one server.

Cache

Choose file, database, or Redis. Use a unique key prefix when sharing a Redis service with another application. JustFlows validates the new store and reverts the setting if it cannot read back a test value.

Queue

• Queue service: database, Redis, or Amazon SQS. Redis is recommended for production.
• Flow execution mode: use Background worker in production. Inline request mode is intended for local testing and debugging.
• Worker process: copy the command displayed on the Queue tab. Its pattern is:

php artisan queue:work DRIVER --queue=QUEUE --tries=3 --timeout=240

Keep the process alive with Supervisor, systemd, Docker, or your platform's worker service. Restart workers after every application deployment so they load the new code.

# WebSockets

Configure Admin → Settings → WebSockets for live interface updates such as workflow-run progress and notifications.

• Pusher: enter App ID, App Key, App Secret, and cluster.
• Soketi: enter host, port, App ID, App Key, App Secret, and the correct TLS setting.

When using a reverse proxy, allow WebSocket upgrades and expose the configured public hostname/port. Test from a real browser over HTTPS; a provider API test alone does not prove the browser connection can upgrade.

# Storage

Select the asset storage driver in Admin → Settings → Storage.

Create the bucket before saving the driver, limit credentials to the required bucket, and configure provider CORS rules for your production domain if browsers access objects directly. After saving, upload and read back a knowledge source or attachment.

# Security and compliance

Review Admin → Settings → Security:

• enable email-based 2FA and decide whether it is enabled for new registrations;
• decide whether users may disable 2FA;
• enforce SSL if HTTPS redirects are not already handled by your proxy;
• configure Cloudflare Turnstile, hCaptcha, or Google reCAPTCHA for authentication forms;
• optionally validate registration addresses with Abstract API.

Then review Admin → Settings → Compliance:

• email-change verification and cookie consent;
• account deletion workflow, cooldown, cancellation, and administrative review;
• blockers that protect shared workspaces, unresolved billing, and active runs/approvals.

Publish accurate Terms, Privacy, Acceptable Use, and other required pages from the Public Pages resource. The optional age-consent dialog is only relevant if your own deployment needs it.

# Customer social login

Social login is separate from workspace integrations. Configure Facebook, X/Twitter, and Google sign-in credentials under Admin → Settings → Profiles → Social Auth.

The page displays the callback URLs generated for your App URL. Their pattern is:

• https://your-domain.example/socialAuth/facebook/callback
• https://your-domain.example/socialAuth/twitter/callback
• https://your-domain.example/socialAuth/google/callback

Create a separate provider application for each environment, register the exact callback, and test both new-account registration and an existing user's login. Social login still respects the platform's email-verification and 2FA behavior.

# Platform OAuth applications

OAuth configuration has two distinct owners:

1. The site owner creates one provider application for the JustFlows installation and stores its shared client credentials in Admin → Settings → Integrations.
2. The workspace user opens the workspace Integrations page and authorizes that shared application for a specific account or workspace.

Before creating provider applications

• Set the final HTTPS App URL under Admin → Settings → General. Callback URLs are generated from that URL.
• For a public development tunnel, set INTEGRATION_OAUTH_BASE_URL to the same public HTTPS origin before copying callback URLs.
• Use a separate provider application and credentials for production, staging, and local/tunnel environments.
• Register every callback exactly as displayed, including scheme, hostname, port, path, and trailing-slash behavior.
• Store secrets only in the JustFlows admin settings or server environment. Do not place them in workspace documentation, screenshots, logs, tickets, or source control.

Google OAuth Web Client

1. Open Google Cloud Console and select the project used by this JustFlows installation.
2. Configure the OAuth consent screen and choose the publishing/audience mode appropriate for your customers.
3. Open Google Auth Platform → Clients. In older navigation, use APIs & Services → Credentials.
4. Create or open an OAuth client whose application type is Web application.
5. In JustFlows, open the Google OAuth tab under Admin → Settings → Integrations and copy each callback URL for the Google integrations you intend to offer.
6. Add every copied URL to the Google client's Authorized redirect URIs.
7. Copy the Google Client ID and Client secret into the same JustFlows tab and save.

Enable the corresponding APIs in the Google project: Gmail API, Google Calendar API, Google Sheets API, Google Drive API, Google Photos Library API, and the Google Analytics Data and Admin APIs. Only enable providers you intend to make available.

Microsoft OAuth

1. Open the Microsoft Entra admin center and create or open the web application used by JustFlows.
2. Copy its Application (client) ID, create a client secret under Certificates & secrets, and copy the secret value immediately.
3. Open Admin → Settings → Integrations → Microsoft OAuth in JustFlows. Copy the Outlook and Microsoft Teams callback URLs into the Entra application as Web redirect URIs.
4. Save the client ID and secret in JustFlows. For a single-tenant application, also save its Directory (tenant) ID; use organizations only when the registration supports organizational directories.
5. For Outlook, add delegated Microsoft Graph permissions offline_access, User.Read, Mail.Send, and Mail.ReadWrite.
6. For Teams, add User.Read, Team.ReadBasic.All, Channel.ReadBasic.All, ChannelMessage.Read.All, and ChannelMessage.Send.
7. Grant tenant admin consent where your Microsoft policy or the requested Teams permissions require it.

Other OAuth providers

Each provider uses the same ownership pattern: create the shared application, register the callback displayed in its JustFlows admin tab, configure only the permissions the integration needs, then save the issued client ID and secret in JustFlows.

Slack

1. Create or open the platform app at Slack API Apps.
2. Under OAuth & Permissions, add the bot scopes required by the enabled workflow actions. The current integration can use chat:write, channels:read, channels:join, channels:manage, groups:read, and groups:write.
3. Open Admin → Settings → Integrations → Slack OAuth, copy the callback URL, and add it to the Slack app's OAuth redirect URLs.
4. Copy the Slack client ID and client secret into the same JustFlows tab and save.

Workspace connections store their own issued bot token and, when verified callbacks or approvals are used, the Slack signing secret. Configure the workspace's displayed interactivity URL under Interactivity & Shortcuts.

Notion

1. Create or open a public integration at Notion integrations. Internal integrations use workspace tokens and do not use this platform OAuth configuration.
2. Enable OAuth for the public integration.
3. Copy the callback from Admin → Settings → Integrations → Notion OAuth into Notion's redirect URI setting.
4. Copy the OAuth client ID and client secret into JustFlows and save.

OAuth authorization does not automatically expose all Notion content. Each workspace must still share the required pages and databases with the connected integration.

Airtable

1. Open Airtable Builder Hub and register or edit the OAuth integration used by the platform.
2. Add data.records:read, data.records:write, and schema.bases:read. Add schema.bases:write only if a future customization creates tables or fields.
3. Copy the callback from Admin → Settings → Integrations → Airtable OAuth into the integration's redirect URL list.
4. Save the Airtable client ID and client secret in JustFlows.

During authorization, workspace users must select the Airtable workspaces or bases the connection may access. Provider scopes alone do not grant resource access.

HubSpot

1. Create or open an app in a HubSpot developer account and open its Auth settings.
2. Register the callback displayed under Admin → Settings → Integrations → HubSpot OAuth.
3. Configure oauth and the read/write scopes used by the integration: contacts, companies, deals, and tickets.
4. Copy the app client ID and client secret into JustFlows and save.

The user installing the app must have permission to authorize it for the selected HubSpot portal. A HubSpot Super Admin may need to approve or perform the installation.

Typeform

1. Open Typeform admin, go to Developer apps, and create or open the platform app.
2. Configure offline, accounts:read, forms:read, responses:read, webhooks:read, and webhooks:write.
3. Copy the callback from Admin → Settings → Integrations → Typeform OAuth into the app's redirect URL list.
4. Save the Typeform client ID and client secret in JustFlows.

Typeform requires public HTTPS URLs for new webhooks. A local installation therefore needs a tunnel whose public origin matches the callback generated by JustFlows.

Shopify

1. Create an app in the Shopify Partner Dashboard that can use OAuth with merchant stores.
2. Set its App URL to the JustFlows workspace integration page, using the production HTTPS domain.
3. Copy the callback from Admin → Settings → Integrations → Shopify OAuth into Allowed redirection URL(s).
4. Configure read_products, read_orders, read_customers, and write_draft_orders.
5. Save the app client ID and client secret in JustFlows.

Calendly

1. Create an OAuth application in the Calendly developer portal.
2. Copy the callback from Admin → Settings → Integrations → Calendly OAuth into Calendly. The HTTPS origin and path must match exactly.
3. Copy the client ID, client secret, and the one-time webhook signing key into JustFlows before leaving the provider setup screen.
4. Save the admin settings and keep the signing key protected; JustFlows uses it to verify inbound booking events.

Use a publicly reachable HTTPS base URL for OAuth and webhook testing. Workflow-specific Calendly webhook subscriptions are created later from the workspace workflow setup.

LinkedIn

1. Create or open the LinkedIn application used by the JustFlows installation.
2. Enable Sign In with LinkedIn using OpenID Connect and Share on LinkedIn for member-profile publishing.
3. For Company Page publishing, request Community Management access and the organization permissions required by the app.
4. Register the callback shown under Admin → Settings → Integrations → LinkedIn OAuth.
5. Save the LinkedIn client ID and client secret in JustFlows.

LinkedIn access tokens commonly require periodic workspace reconnection. Test both member and organization publishing paths before making Company Page actions available.

Instagram

1. Create a Meta application and add the Instagram API product using Instagram Login.
2. Request instagram_business_basic, instagram_business_content_publish, and instagram_business_manage_comments.
3. Add the callback from Admin → Settings → Integrations → Instagram OAuth to the app's allowed OAuth redirect URLs.
4. Save the Meta app ID as the client ID and the app secret as the client secret in JustFlows.

Publishing requires an Instagram Business or Creator account and a public media URL that Meta can download. Personal Instagram accounts are not supported by these actions.

Sentry

1. Create an OAuth application from the settings of the Sentry organization used for platform testing.
2. Use org:read, project:read, and event:read for read-only triage. Add event:write only when workflows may resolve, ignore, assign, or prioritize issues.
3. Register the callback from Admin → Settings → Integrations → Sentry OAuth.
4. Save the Sentry client ID and client secret in JustFlows.

Regional Sentry organizations may use a regional API base URL at the workspace connection level; that is separate from the shared OAuth client configuration.

Zendesk

1. In Zendesk Admin Center, open Apps and integrations → APIs → Zendesk API → OAuth Clients.
2. Create a client for the JustFlows installation and register the callback from Admin → Settings → Integrations → Zendesk OAuth.
3. Save the Zendesk unique identifier as the client ID and save the issued secret in JustFlows.

Each workspace supplies its own Zendesk subdomain when connecting. The shared OAuth client should be tested against a non-production support account before customer rollout.

Verify the platform setup

1. Save the admin settings without exposing the credentials to a workspace user.
2. From a test workspace, open the provider on the Integrations page and start its OAuth flow.
3. Confirm the provider consent screen returns to the expected JustFlows hostname and creates the workspace connection.
4. Run the integration's safe connection test, then exercise one non-destructive read action before enabling it for customer plans.

# Workspace subscription payments

Use Admin → Settings → Payments to sell workspace plans. Configure the currency code, symbol, and display position before creating plans.

The admin page shows the exact URL generated for the current App URL. Copy that value into the processor dashboard. Test callbacks over HTTPS before switching to live mode.

The Invoices tab controls whether payment invoices are generated and contains your legal sender identity and invoice prefix. Configure Taxes separately when your pricing requires them.

# Plans and entitlements

Create plans under Admin → Billing → Plans. A plan controls both price and product capacity:

• monthly and yearly price, status, display order, and one-time trial duration;
• members per workspace and monthly workflow runs;
• monthly Flowy messages and access to human approval steps;
• maximum AI agents, MCP servers, and knowledge bases;
• knowledge-source storage allowance;
• all integrations or a selected integration allowlist.

Keep one suitable default plan for new workspaces. Before lowering a live plan limit, review current customer usage so the change does not strand existing resources. Confirm that the scheduler processes trial and subscription lifecycle changes.

# Global AI settings

Use Admin → Settings → AI to control platform-wide AI features and defaults.

• General: enable text and image generation and choose whether prompts are logged.
• Text: default provider, model, output-token budget, and temperature.
• Images: default image provider and model.
• Providers: platform credentials and optional base URLs.

Supported provider families include OpenAI, Ollama, Anthropic, Qwen, MiniMax, Google, DeepSeek, Kimi, Z.ai, Mistral, and xAI. Available models are presented by the application; model catalogs change, so select a model that is available to your provider account and region.

Platform provider keys support global defaults and Flowy. Customer agents can instead use credentials saved in the workspace's AI Accounts area, keeping customer billing and data boundaries separate.

# Flowy workflow assistant

Flowy helps workspace editors understand, draft, and change workflows. Enable it only after global text generation works.

• Store or disable workspace-visible conversation history and set its retention period.
• Use the default text model or select a dedicated Flowy provider/model.
• Limit prompt context, response tokens, and temperature.
• Allow prompt-to-flow drafts and/or proposed edits to existing flows.
• Allow suggestions for integrations the workspace has not connected yet.
• Allow selected or recent run-failure context to help troubleshoot a flow.

Flowy proposes changes; workspace editors still review and apply them. Plan entitlements can limit monthly Flowy messages or disable Flowy for a workspace.

# Prompt logging and privacy

Prompt logging is disabled by default. If enabled, choose the least revealing mode that still supports diagnosis:

• Hash only: safest correlation option without readable prompt content.
• Hash + short preview: useful for short-lived troubleshooting, but may expose customer data.
• Full prompt: maximum diagnostic detail and maximum privacy risk.

Limit access to AI logs, document your retention policy, and disable detailed logging after the investigation. Also review the data-use policies of every provider your platform or customers connect.

# Workspaces and teams

A workspace is the ownership and billing boundary for orchestration resources. Workspace owners and permitted members can invite teammates, assign roles, switch workspaces, and collaborate on flows and approvals.

• Member limits include the workspace owner and pending invitations.
• Only authorized workspace roles can manage billing, secrets, integrations, or destructive actions.
• Removing a member should not be treated as deleting the resources they helped create.
• Account deletion can be blocked while the user owns a shared workspace or has active operations/billing.

Administrators can inspect workspaces and members from the admin panel when supporting a customer. Use impersonation carefully and record why it was necessary.

# Workspace AI accounts

Workspace AI Accounts hold provider credentials used by that workspace's agents. A customer should:

1. open AI Accounts and choose a provider;
2. save the API key and any custom base URL required by that provider;
3. select the account when configuring an agent;
4. run a small test before using it in a published workflow.

Credentials are secrets. Workspace members only see or reveal them according to their permissions. When rotating a key, re-test every agent that depends on the affected account.

# Agents, prompts, and skills

• Agents combine an AI account/model with instructions and optional capabilities. Plan limits control how many a workspace can create.
• Prompts are reusable, versioned instructions. Versioning gives workflows a stable reference and an audit trail.
• Skills add reusable behavioral guidance or domain-specific instructions to an agent.

Keep agents focused. Give tools and data access only when required, test structured outputs, and use lower-variance settings for automation that must return predictable fields.

# Knowledge bases and MCP servers

Knowledge bases store workspace sources that an agent can use as context. Plan entitlements limit both the number of knowledge bases and their stored source size. When ingestion fails, check the chosen storage driver, upload limits, file type, worker, and logs.

MCP servers expose additional tools to the workspace. Add the server URL and credentials, validate the connection, and discover capabilities before attaching it to an agent or flow. Treat an MCP server as privileged code: review who operates it, what tools it exposes, and what data it can access.

# Flow lifecycle and templates

1. Create a blank flow or launch a starter template.
2. Resolve the template's setup checklist: plan access, integrations, AI accounts, agents, and other required resources.
3. Add and connect nodes, then configure mappings and error paths.
4. Save the draft and run a manual test with representative data.
5. Publish the version that should receive triggers.
6. Monitor run history and create a new draft for later changes.

Templates accelerate common automations but do not supply customer secrets. The launch checklist identifies missing connections and plan restrictions before publication.

# Triggers

Only an active trigger attached to a published flow can start a production run. Use request IDs on external webhooks to trace or de-duplicate upstream events.

# Node types

Map outputs explicitly between nodes and test empty, missing, and unexpected values. Use Stop for a deliberate early exit and keep End for the normal completion path.

# Approvals and run history

An Approval node pauses a run until an authorized workspace member approves, requests changes, or rejects it. Approval availability is controlled by the workspace plan. Email and optional Telegram notifications depend on the corresponding platform and workspace connections.

Run history is the first place to diagnose a workflow:

• confirm the published version and trigger event;
• identify the last node and current run status;
• inspect safe input/output summaries and the error message;
• verify the required integration, AI account, or entitlement;
• check queue, provider, and application logs if execution never reached the node.

Do not paste customer secrets into support tickets. Redact API keys, authorization headers, cookies, personal data, and raw provider payloads.

JustFlows includes a dedicated workspace guide with current connection fields, authorization steps, tests, capabilities, and troubleshooting notes. Platform-owned OAuth application setup stays in the site-owner section above because workspace users cannot access the shared admin credentials.

Open the full integration guide

From an owner perspective, remember the separation:

• enable and manage the global integration catalog in the admin panel;
• configure shared OAuth client credentials under Admin → Settings → Integrations;
• allow all or selected integrations through each plan;
• customers connect and test credentials inside their workspace;
• workflow Tool nodes use those validated workspace connections.

A workspace can expose a published workflow through a generic webhook trigger. The flow builder supplies the trigger's public ID and secret.

Start a run

curl -X POST "https://your-domain.example/api/v1/webhooks/PUBLIC_ID" \
  -H "Authorization: Bearer WEBHOOK_SECRET" \
  -H "Content-Type: application/json" \
  -H "X-Request-Id: order-1234" \
  -d '{"customer_id": 42, "event": "order.created"}'

The secret may instead be sent in X-JustFlows-Webhook-Secret. A valid request returns HTTP 202 with the flow run ID, trigger event ID, current status, and a run_status_url.

Read run status

curl "https://your-domain.example/api/v1/webhooks/PUBLIC_ID/runs/RUN_ID" \
  -H "X-JustFlows-Webhook-Secret: WEBHOOK_SECRET"

• Store the secret in a secret manager and rotate it if exposed.
• Use a stable, unique X-Request-Id for tracing.
• Treat 202 as asynchronous acceptance, not completed work.
• Set upstream timeouts and retries appropriate for an asynchronous endpoint.
• Deactivate the trigger before deleting or replacing an external integration.

The admin panel is available at https://your-domain.example/admin. The first administrator is created by the installer. You can promote an existing user from the application directory with:

php artisan make-admin user@example.com

Use roles and permissions to give additional administrators only the access they need.

# System health and monitoring

The admin dashboard and System Health page summarize the application, scheduler heartbeat, queue, cache, storage, logs, and runtime versions. Operational widgets also surface workflow reliability, failure hotspots, AI usage, Flowy diagnostics, and subscription activity.

When a customer reports a stuck or failed workflow, check in this order:

1. the flow is published and its trigger is active;
2. the workspace still has plan access and remaining usage;
3. the queue worker and scheduler are healthy;
4. the required workspace integration or AI account still validates;
5. the run's last node and error details;
6. storage/logs/laravel.log and relevant provider/payment logs.

Monitor the queue backlog, failed jobs, disk/database growth, external API failures, payment webhook delivery, SSL expiry, and backup age. Configure external uptime monitoring for both the public site and a workflow smoke test.

# Backups and recovery

A usable backup includes:

• the complete database;
• the .env file and any deployment-specific configuration;
• storage/, including the install marker, private files, and local uploads;
• remote object-storage buckets or their replication/versioning policy;
• custom themes, templates, or code changes kept outside the original package;
• worker, cron, proxy, and WebSocket service definitions.

Encrypt backups, restrict access, keep copies outside the application server, and test restores. A database-only restore may leave missing knowledge sources or mismatched attachments; a file-only restore may leave resources the database no longer references.

1. Read the release notes and compare new requirements with your server.
2. Back up the database, .env, storage, and customizations.
3. Enable maintenance mode or otherwise prevent writes while replacing application files.
4. Download the latest Envato archive and replace the application with the contents of its Script directory. Preserve your .env and required persistent storage.
5. Visit https://your-domain.example/update while signed in as an administrator and complete the database update wizard.
6. Clear application caches if the release notes require it and restart every queue worker.
7. Disable maintenance mode and run the launch smoke test: login, email, storage, AI, integration, queued flow, webhook, scheduled flow, approval, and payment callback.

If the installer appears after an update, confirm storage/app/installed was preserved. If the application fails before the update wizard loads, inspect storage/logs/laravel.log, PHP compatibility, file ownership, the restored .env, and whether the complete vendor/ directory was uploaded.

# Why does my URL contain /public?

Your domain points at the application directory instead of its public/ subdirectory. Correct the web server document root; do not move .env or application code into the public web directory.

# Why do I get a 500 error after uploading?

Check storage/logs/laravel.log. Common causes are a missing hidden file, unsupported PHP version, missing extension, unwritable storage/ or bootstrap/cache/, incomplete upload, invalid .env, or database connectivity.

# Why do workflows remain queued or stop after the first request?

Confirm Admin → Settings → Runtime → Queue is configured, the flow uses Background worker mode, and the displayed worker command is running continuously. Then inspect failed jobs and application logs.

# Why are scheduled, email-triggered, or waiting flows not resuming?

These features depend on php artisan schedule:run every minute. Check the cron entry, PHP path, application path, server timezone, scheduler heartbeat, and logs.

# Why does an OAuth provider reject the callback?

Make sure the production App URL is correct and that the callback URL displayed in the JustFlows admin setting exactly matches the provider application. Check HTTPS, hostname, port, trailing slash, provider scopes, client secret, and environment-specific applications.

# Why do AI calls fail while the key looks correct?

Confirm the selected model is available to that provider account and region, the base URL is correct, outbound HTTPS works, credit/rate limits allow the call, and the workspace agent uses the intended AI account. Review the run error and provider response without exposing the key.

# Why do uploads fail after changing storage?

Verify the bucket exists, credentials and region/endpoint are correct, the web and worker processes use the same settings, required CORS/public URL rules are present, and the provider permits the requested operation. JustFlows reverts a storage setting when its validation check fails.

# Why does the public webhook return 401 or 404?

401 means the Bearer token or X-JustFlows-Webhook-Secret is missing or wrong. 404 means the trigger is missing/inactive or the requested run was not created by that trigger. Also confirm the flow version is published.

# Why can a workspace see a feature but not use it?

Review its active subscription/trial, current usage, and the plan entitlements for integrations, approvals, Flowy, agents, MCP servers, knowledge bases, storage, members, and monthly runs.

# Getting support

For product support, contact Qdev Techs through the Envato author profile. Installation and customization services are also available from Qdev Techs services.

Include the JustFlows version, PHP version, hosting type, affected area, reproducible steps, timestamp/timezone, and the relevant redacted log excerpt. Never send .env, purchase codes, payment secrets, AI keys, OAuth client secrets, cookies, or unredacted customer payloads.