How to Build Workflows with Process Builder in Joget
Date
Aug 10, 26
Reading Time
11 Minutes
Category
Low-Code/No-Code Development
Share
Your team approves leave requests over email. Someone misses the thread, the request sits for four days, and the employee follows up twice before anyone signs off. Multiply that across purchase approvals, claim reviews, and vendor onboarding, and you get a company that runs on reminders instead of process.
A written workflow fixes half of it. You still need someone to push each step forward.
Joget's Process Builder handles that push. It's a drag-and-drop canvas inside Joget's App Designer where you map out who does what, in what order, and under what conditions. No code. You draw the flow, assign the people, publish, and the engine routes work on its own from there.
I'll walk through the setup, the build, the testing, and the five problems that break most first workflows. Plus where I think Process Builder stops being the right tool.
What Is Joget Process Builder?
Joget Process Builder is a low-code, drag-and-drop workflow designer inside Joget's App Designer. You place activities, connect them with transitions, and add decision points to control branching. The engine then assigns tasks, tracks deadlines, and moves each request through the process without anyone chasing it manually.
It sits alongside the Form Builder and the App Builder in Joget. Forms collect the data. The process decides where that data goes and who touches it next.
What you get out of it:
- One view of the whole process, so nobody argues about who owns step four
- Task routing by role or group instead of by named person
- Conditions that branch on form data, no scripting required
- Direct links between forms, apps, and process steps
Setting Up Joget Before You Open Process Builder
Get three things right before you draw anything: your Joget version, your environment, and your permissions.
Version. Process Builder ships with Joget DX 7 and later. DX 9 is the current release, and if you're on anything older than DX 7 you're missing pieces of the designer.
Environment. Two paths here:
- Joget Cloud. Sign up and start building. Nothing to install, and it's the faster route for a first workflow or a proof of concept.
- Self-hosted. Pick this when you need control over data residency, network placement, or custom plugins. You'll need a supported JDK for your DX release, a database (MySQL or PostgreSQL), and a servlet container like Tomcat.
Check the version notes for your specific DX release before you provision the JDK. The supported Java version changed between DX 7 and DX 9, and a mismatch here costs you an afternoon.
Permissions. Open your app in App Designer and look for the Processes section. If you can't see it, your role lacks design rights. Admins and app designers have them by default. Everyone else needs them granted.
Relinns has deployed Joget across enterprise environments in the UAE, EU, and US as a certified DX 9 partner, and the setup step is where most in-house teams lose time. If you want to see what a production build looks like end to end, our walkthrough on building process tracking software with Joget covers the full architecture.
How Do You Create a New Process in Joget?
Open App Designer, go to Processes, and click New Process. Drag a Start Event, one or more User Tasks, and an End Event onto the canvas. Connect them with transitions. Set the process ID and participants in the Properties panel, name the process, and save. The process is now available to your app.
Four steps, in order:
Lay out the skeleton. Start Event, the tasks in between, End Event. Get the happy path on the canvas before you touch conditions or edge cases.
Set process properties. Open the Properties panel and fill in the process ID, a description someone else will understand in six months, and the participant list.
Map participants to real groups. Link each participant to a Joget user group or role. Naming a person here is the single most common mistake, because that person leaves and the workflow breaks.
Name it and save. Use something a colleague can find. "HR_LeaveApproval_v1" beats "Process 3."
Save often. The canvas doesn't autosave on every change.
Related reading: how to build external service workflows with Joget API Builder.
Designing the Workflow: Activities, Transitions, and Decisions
Designing a workflow means translating a business rule into something the engine can execute. Three building blocks do the work.
Activities
Activities are the steps. Joget gives you two kinds.
User Tasks need a human. An employee submits a leave request. A manager approves it. A finance officer verifies an invoice amount.
System Tasks run without a human. Sending an email, writing to a database, calling an external API, updating a record.
Drag the shape onto the canvas, then open Properties. For a User Task, assign the role. For a System Task, configure the plugin or script that fires.
Transitions
Transitions are the arrows. Draw one from each activity to the next and you've defined the sequence.
You can run steps in order or fire several at once. A purchase request that needs both finance sign-off and IT security review doesn't have to queue them, you can branch into parallel paths and rejoin after both finish.
Add a default transition wherever conditions might all evaluate false. Skip this and requests get stuck at that node with no error message telling you why.
Decision Points
Decision points are the diamonds, and they read conditions off your form data, user roles, or external sources.
A leave workflow might do this:
- 3 days or fewer: approve without a manager
- More than 3 days: route to the manager
- More than 10 days: route to the manager, then HR
That's real branching logic with zero custom code, which is the main reason ops teams pick Joget over writing a service themselves.
Also worth reading: Joget AI Agent Builder and why it matters.
A Worked Example: Leave Approval
Here's the full flow for the leave process above.
| Step | Type | What happens |
|---|---|---|
| 1 | Start Event | Employee opens the leave request form |
| 2 | User Task | Employee submits dates and reason |
| 3 | Decision Point | Engine reads number of days requested |
| 4a | System Task | 3 days or fewer, record approved, no human involved |
| 4b | User Task | More than 3 days, routed to the employee's manager |
| 5 | Decision Point | Manager approves or rejects |
| 6 | System Task | Email fires to the employee with the outcome |
| 7 | End Event | Request closed and logged |
Seven nodes. An HR team can read that diagram without a training session, and that readability is the point. When the process lives on a canvas instead of in someone's head, the arguments about who dropped the request stop.
My honest take: most teams over-model their first workflow. They add every exception they can imagine, end up with 30 nodes, and nobody can debug it. Ship the seven-node version, watch where it actually breaks, then add branches. Process Builder also gets unreadable past roughly 15 to 20 nodes on one canvas, so if your flow is heading that way, split it into sub-processes instead.
Configuring Assignments, Deadlines, and Workflow Variables
A drawn workflow isn't a running workflow. Three settings turn the diagram into something that behaves.
Assignments
Every User Task needs an assignee. Joget lets you point at an individual user, a role, or an organizational group.
Use roles and groups. "Employee's Manager" survives a reorg. "Priya from Finance" doesn't. Joget can resolve the reporting line from your org hierarchy, so a leave request finds the right manager without you hardcoding anyone.
Deadlines and Escalation
Set a duration on each task, say two business days for a manager approval. When the clock runs out, Joget can reassign the task, notify a supervisor, or both.
Workflow Variables
Variables hold the data your process needs to make decisions. Leave days requested. Claim amount. Request type. Region.
They do three jobs: carry form input into the process, pass values between tasks so a later form can show what an earlier one captured, and feed decision points so branching reads live data.
Standardize your field names across forms and processes before you build. Mismatched names are behind a large share of the "data not saving" tickets I've seen.
Connecting Forms and Apps to Your Workflow
Forms are where data enters. The process decides what happens to it. Link the two and the workflow runs on real input instead of test values.
Assign a form to each activity. Different roles should see different forms. The employee's submission form and the manager's approval form are not the same screen, and giving the manager the full editable form invites errors.
Set a start form. One form triggers the process. Make the fields you need for routing mandatory here, because a decision point can't branch on data that was never captured. Request type, requester ID, and whatever your first condition reads on.
Pass data forward. Map form fields to workflow variables, then configure auto-population so downstream tasks display what came before. A manager approving leave should see the dates without opening a second tab.
Validate at the form, not the process. Catching a bad date range at submission costs one user five seconds. Catching it three steps later costs an admin twenty minutes.
How Do You Test a Joget Workflow Before Publishing?
Run the process in test mode with sample users assigned to each role, walk every branch including rejections and escalations, then repeat the same passes on mobile. Use the workflow instance viewer to confirm task progress and variable values, and check server logs for plugin or transition errors before you publish.
Desktop Testing
Launch the process in test mode. Assign sample users to each role and confirm the task lands with the right person. Walk the approval path, then walk the rejection path, then trigger an escalation by letting a deadline lapse.
Testing the happy path only is how broken rejection flows reach production.
Mobile Testing
Managers approve things from phones. Open the workflow in a mobile browser or the Joget mobile app, claim a task, complete it, and check that notifications land and forms stay usable at that width.
If your approval form needs horizontal scrolling on a phone, your approvals will be slow no matter how clean the process diagram is.
Debugging
The workflow instance viewer traces each request through the flow. Use it to see where an instance is sitting and which variables it's carrying. Server logs catch the rest: plugin exceptions, script failures, misrouted transitions.
Re-run with sample data after every fix. Republishing a corrected definition without re-testing is how the same bug ships twice.
Best Practices for Building Workflows in Joget
Four habits separate workflows that survive a year from workflows that get abandoned.
Keep it simple. Cut loops, redundant approvals, and routing nobody can explain. If a step exists because "we've always done it," that's a reason to question it, not keep it.
Name things for the next person. Tasks, forms, and variables all need names that make sense to someone who wasn't in the design meeting. "Submit Leave Request" over "Task1."
Document alongside the canvas. Keep a short flowchart and a paragraph on the business rules outside Joget. The diagram shows the sequence. It doesn't explain why leave over 10 days needs HR.
Version deliberately. Publish, note what changed, and keep the old definition available. Joget tracks versions, and you'll want the rollback path the first time a condition misfires in production.
Common Joget Process Builder Problems and Fixes
Five issues account for most first-build failures.
| Problem | Usual cause | Fix |
|---|---|---|
| Workflow won't advance | Missing transition, unmapped condition, or unpublished definition | Check every activity has a connected outgoing transition, verify condition references resolve, republish and confirm you're testing the live version |
| Task goes to the wrong person | Participant mapped to a stale role or a named user | Re-map to a role or group, test with sample users, sync your org hierarchy or directory integration |
| Form data doesn't save | Field names don't match variable or column names | Compare form field IDs against workflow variables and the database schema, then run a query to confirm writes |
| Notifications never arrive | SMTP misconfigured, or template references an empty variable | Test the SMTP connection on its own, then confirm the recipient variable holds a value at that point in the flow |
| Process errors out mid-run | Plugin missing required parameters, or a script exception | Read the server log for the exception, fix the plugin config, republish the definition |
Bottom Line
Process Builder earns its place when you have a repeatable process with clear owners, defined conditions, and enough volume that manual chasing costs real hours. Approvals, onboarding, claims intake, audits, service requests.
It's less suited to processes that change weekly, or logic dense enough that you'd be fighting the canvas instead of using it. Know that boundary going in and you'll pick the right tool more often.
Start with one process. The seven-node version. Get it running, watch the first fifty requests, then expand.
Working with a Certified Joget Partner
If you'd rather not learn Process Builder on a production process, Relinns builds Joget workflow systems as a certified DX 9 partner, with enterprise deployments across the UAE, EU, and US.
What our clients see:
- 90% of workflows we build need zero coding from your team
- 40% faster deployment than traditional BPM tooling
- 75% fewer process errors after automated approvals, escalations, and structured testing
- Integrations with 95% of the enterprise systems we've encountered
- 60% quicker iteration cycles, so process changes ship in days
Get a free Joget consultation and we'll scope your first workflow on the call.
Frequently Asked Questions
How is Joget Process Builder different from traditional BPM tools?
Joget Process Builder uses a drag-and-drop canvas instead of code or BPMN modeling suites that need specialist training. Business analysts can build and change workflows themselves, which cuts deployment time. Traditional BPM platforms offer deeper modeling depth but usually require developer involvement for every change.
Can Joget Process Builder connect to a CRM or ERP?
Yes. Joget supports REST API integration and plugin-based connectors, so a workflow can read from and write to Salesforce, SAP, a warehouse management system, or an internal database. System Tasks handle the calls, and you configure endpoints and authentication without writing the integration layer yourself.
Which industries use Joget Process Builder most?
Insurance, banking, healthcare, and logistics see the heaviest use, because those sectors run high volumes of approval and compliance workflows. Common builds include claims processing, credit application review, patient intake, purchase approvals, and audit trails where every step needs a timestamp and an owner.
Is Joget Process Builder secure enough for regulated industries?
Joget provides role-based access control, audit trails on every process instance, and encrypted data handling. Self-hosted deployments let you control data residency, which matters for GDPR, HIPAA, and UAE PDPL obligations. Compliance depends on how you configure and host it, not on the platform alone.
Does Joget Process Builder scale for large organizations?
Yes. Joget scales horizontally across application servers and vertically on larger instances, and enterprises run it across thousands of users and concurrent process instances. Performance at scale depends on database tuning and infrastructure sizing more than on the workflow design itself.
What version of Joget do I need for Process Builder?
Process Builder is available in Joget DX 7 and later, and DX 9 is the current release. Older versions lack parts of the designer. Check the release notes for your version before setting up a self-hosted environment, since supported Java and database versions changed across DX releases.
