STEP 01
From a request to accountable work
WorkflowRight brings business information, forms and manual tasks into configurable applications. Use it to make handoffs visible: what was requested, who can act, what decision was made and what happens next.
Build on the web; do work on Android
Owners and authorized builders use the web platform to configure data, forms, processes, roles and application navigation. Team members use permitted web queues or the Android companion to open assigned or eligible work, fill the configured form and submit an outcome. Android is a companion, not the application designer.
A small, fictional first project
This walkthrough uses Demo Service Team as the organization, Operations as its workspace and Service Requests as its application. DEMO-REQ-001 is a fictional service request. Use invented labels only; no real customer, payment or private contact details are needed. The exercise follows the Service Company starter's manual New service request process and does not require a purchase.
Know the boundaries
A starter supplies a configurable starting point, not a complete industry system. The service starter does not provide GPS tracking, route optimization, payment processing, invoicing or inventory control. Related record references are coordinated by people; creating a request does not automatically create a dispatch or completion report.
STEP 02
Understand the building blocks
Think of the structure as Organization > Workspace > Application. Inside an application, data, forms and processes describe the work. Roles control access; records and tasks are the work being performed.
Organization and workspace
The organization is the membership, security and subscription boundary. A workspace groups applications for a team or area such as Operations. A person's permissions may apply across the organization or only within a chosen workspace or application.
Application, data and forms
An application combines a business purpose with its definitions and navigation. An entity describes a kind of information, such as Service Request. Its fields define allowed values and required details. A record is one saved instance of that information. A form presents fields for people to enter or review.
Processes, roles and tasks
A process defines steps and decision paths. Starting a published process for a record creates an instance. A manual step creates a task. A role groups explicit permissions; process assignment selects the person or role eligible for a task. Eligibility and permission are separate checks.
Names versus keys
For new organizations, workspaces, applications, roles, entities, fields, forms, processes and rules, enter a business name or label; WorkflowRight generates the technical identity. Renaming a label keeps its stable key and existing references. Technical details show keys read-only. Advanced process variables, routing outcome keys and import/package identities remain explicit because expressions, mappings and paths refer to them. Change their labels without changing their keys.
STEP 03
Create your organization and workspace
Start in the web platform with an account you control. Complete the sign-in or sign-up verification requested on screen; normal accounts may require verification codes or other checks.
1. Create the organization
Open the WorkflowRight sign-up page. Once signed in, use the organization creation form and enter Demo Service Team as the organization name. If you already belong to an organization, first confirm which organization you intend to use. Do not create duplicates to work around an access error.
2. Create Operations
In Overview, find Your workspaces. Enter Operations in Workspace name and select Create workspace. Organization owners can use this creation control. Workspaces organize applications; they do not independently create employee permissions.
3. Choose a starting point
Applications offers a blank application and the Industry Starter Library. A blank application requires you to create and publish the definitions yourself. For this tutorial, use the Service Company starter after preparing roles in the next section. Reserve Service Requests as the application name.
Before proceeding
Check that your organization has capacity for another application and that your account can create applications, install packages and manage the required roles. Free includes application creation and templates within its allowances. A guide or PDF download never grants protected access.
STEP 04
Prepare roles before installing
The starter maps its manual-task responsibilities to roles that already exist. Installing it does not create employees, grant permissions or assign people to roles.
1. Create scoped roles
Open Roles and choose Create role. Use distinct names such as Service Owner, Service Dispatcher, Service Technician and Service Reviewer. Choose WORKSPACE scope and Operations so the roles can exist before the application does. Select only the permissions needed, then Save. For this manual task exercise, task.complete is the task permission to check. Builder and organization-management permissions are not required for an ordinary worker.
2. Assign a person
Use Members to assign the relevant roles to an eligible organization member. For a solo fictional exercise, you can assign all four service roles to your own member account. This is for learning the paths; a real team should divide responsibilities and use the narrowest suitable scope. Invitations and role assignments are separate actions.
3. Keep two access checks in mind
A role's permission allows an operation within its scope. A process's candidate or assignee rule determines whose task it is. A user can have task.complete and still not be eligible for a particular task. Conversely, mapping a role without an assigned, permitted member can leave work with nobody able to complete it.
Owner is not a magic role name
The protected organization-owner relationship is different from a configurable role named Owner or Service Owner. Naming a role Owner does not grant owner powers. Avoid duplicate role keys across applicable scopes because starter mapping must resolve a responsibility unambiguously.
STEP 05
Preview and install the service starter
Return to Applications and choose Browse industry starters to open the Industry Starter Library. Select Service Company - Work Coordination (displayed with a long dash in the catalog). Read its included objects and limitations before choosing Use this starter.
1. Map responsibilities
Choose Operations as the workspace and Service Requests as the application name. Map Owner to Service Owner, Dispatcher to Service Dispatcher, Technician to Service Technician and Reviewer to Service Reviewer. These are responsibility mappings to existing roles, not member invitations. If a role is missing, return to Roles, correct its scope or create it, then reopen the installer.
2. Review the preview
Select Validate and preview. Check the application name, workspace, definitions, mappings, warnings and quota results. Correct any blocking issue. A warning about assigned members means you must verify who can perform the work before starting it. Changes to selections require a fresh preview.
3. Install the independent copy
Choose Install application and confirm the installation. The copy contains definitions and supported presentation assets, not users, customer records, task history or running process instances. Imported triggers remain disabled. Catalog updates do not automatically synchronize into your application.
4. Open Setup
Use the Application Setup Guide in the Setup tab. Review structure, fields, forms, outcomes, assignments, navigation and reports. User acknowledged records your review; System verified reports specific database facts. Neither label certifies that every path has been tested or that the application is operationally approved.
STEP 06
Review definitions, then make a record
The starter already supplies published entity, form and process versions. Review them before entering information. Customize through new drafts and publication rather than assuming a change affects existing work.
Review the matching definitions
In the application's Data area, inspect Service Request and its required fields. In Forms, review the service-request form. In Processes, inspect New service request: it starts with Confirm requested service and availability, then routes to dispatch handoff or out-of-scope review. Confirm the mapped roles and exact published form references.
Understand version pinning
A process references specific published forms. Publishing a revised form does not silently update those references. After customization, publish the intended process version with the correct form references. Running instances retain their pinned process version and its form references; use a new instance to test the revised path.
Create DEMO-REQ-001
Open Service Request records from Data and use the record creation control. Enter Reference: DEMO-REQ-001; Work status: New; Customer reference: DEMO-CUSTOMER-001; Service type: Inspection; Request summary: Fictional appliance inspection for training. Optional Coordination notes can say No real customer or delivery. Save the record and check the saved values.
References are not hidden automation
Customer reference is text in this starter, so the fictional reference does not automatically create or link a customer record. Work status is also a field you update explicitly. Selecting a task outcome routes the process; it does not automatically rewrite that status field.
STEP 07
Start and complete your first process
Creating a record alone does not start this manual process. Keep imported automations disabled for the exercise and start the published process explicitly.
1. Start the matching process
In Processes, choose Start process for New service request. In Record, select DEMO-REQ-001 and select Start process. Confirm the instance was created before starting again; repeated independent starts can create separate work for the same record.
2. Find and claim the work
Open the application's My Work queue as the intended member. Find Confirm requested service and availability. If it is available candidate work, use Claim task before completing it. Open the form, review the fictional request and fill any required fields. If it is already assigned to another member, ask the responsible manager to review assignment.
3. Follow the positive path
Submit the supported outcome. The process should advance to Confirm dispatch handoff. Open that task as an eligible Dispatcher, review the form and submit complete. Inspect the instance and task history to confirm it reached Coordination complete. Update Work status explicitly if you want the record to reflect the decision.
4. Try an exception separately
Create a second fictional record, DEMO-REQ-002, and start a new instance. This time submit outside scope. The starter routes to Review an out-of-scope request for the mapped Owner responsibility, then complete ends the path. Other starters use different outcomes. Follow-up processes start separately; this starter does not loop or automatically create related records.
STEP 08
Continue the work on Android
Use the WorkflowRight Android companion distributed through your authorized Google Play release or testing channel. The web platform remains the place to design and administer the application.
Sign in and confirm the organization
Use the same account and complete the normal sign-in checks. Select the intended organization when asked. The companion operates in a single bound organization; confirm its displayed name before working or managing subscriptions. Do not assume a task from another organization will appear.
Open your work
Use Open my work or the Tasks tab, which presents My work. Open an assigned or eligible task, claim it when required, fill its published form and submit one of its configured outcomes. Keep a network connection available and verify the resulting state rather than assuming an interrupted submission succeeded.
Compare web and mobile results
For a learning check, start a fresh fictional instance on the web and complete one task on Android. Reopen or refresh the web queue and inspect the process history. The same server-side permissions, task eligibility and version references apply on both interfaces.
Access and subscriptions
The organization subscription is separate from your personal login. Only authorized billing managers can purchase for the bound organization. Google Play and RevenueCat supply billing evidence, but the WorkflowRight backend verifies organization access. Local purchase state alone does not grant paid capabilities. A purchase is unnecessary for this manual starter exercise.
STEP 09
Plan capacity and protect access
Plans apply to an organization, not separately to each workspace or device. Permissions still govern what each member may do within the plan's allowances.
Free supports the manual exercise
The standard Free plan includes application creation and templates, with 3 applications, 3 active members and 100 MiB of private storage. Manual forms and manual-task workflows are available within their permissions and limits. Free does not include paid automated actions, timers, REST integrations or incoming webhooks.
Paid plans add capabilities and capacity
Professional has standard allowances of 25 applications, 25 active members, 1 GiB storage and 10 REST connections. Business has 100 applications, 100 active members, 5 GiB storage and 50 REST connections. Both include paid actions, timers, REST and webhooks. Check Pricing and your organization subscription for current effective allowances; these are not unlimited plans.
Use explicit, narrow access
Organization boundaries isolate access. Roles and scope further restrict operations; task assignment adds eligibility rules. Invite only intended members, review permissions and keep administrative rights with those who need them. A public guide or exported handbook reveals no private workspace data and confers no access.
Review before enabling automation
Imported triggers stay disabled until explicitly reviewed and enabled by an authorized person. Check targets, duplicate-start behavior, plan eligibility and operational scheduling before use. A paid plan alone does not turn every automation on. Review your own privacy and regulatory obligations; this guide is not a compliance certification.
STEP 10
Troubleshooting and next steps
Start with the organization, application and exact operation that failed. Keep private data out of support messages and never send passwords, tokens or signing keys.
No tasks or no eligible mapping roles
For missing tasks, confirm the organization, published process start, current instance step, queue filters, candidate or assignee eligibility and task.complete permission. For missing starter roles, create them before installation in an applicable scope and assign members separately. Resolve ambiguous mappings instead of bypassing validation.
Published form needed or access denied
Check that the process references a published form for the correct entity. Publish and reference a new version deliberately when changing definitions. For access denied, ask an owner or authorized role manager to check membership, scope and explicit permissions. A task assignment alone does not grant permission.
Limit reached or automation inactive
Review organization allowances and current usage. Archiving an application does not automatically free an application slot. Imported automation is intentionally disabled; review and enable only what you understand and are entitled to use. Do not start extra instances merely to compensate for an unclear queue.
Sign-in verification
Follow the normal account verification prompts and use account recovery when appropriate. Special Google Play reviewer arrangements are not a promise that ordinary accounts can sign in without verification.
Where to go next
Return to the application's Setup tab and record your review. Adapt one field or outcome in a new version, then repeat the fictional positive and exception paths. Read the public platform and governance guides for design context. For product questions, use the Contact page; for personal-data requests, use the Privacy request form.