Timers, BPT Processes, Human Activities, and Built-in Functions
Key Takeaways
- A Timer is a server-side scheduled background job that runs a configured Server Action at set intervals (e.g., nightly), used for batch notifications, data purges, and external syncs — not for client-side timing or UI countdowns.
- BPT (Business Process Technology) is OutSystems' built-in workflow engine for long-running, stateful processes spanning days or weeks, composed of Human Activities, Automatic Activities, Wait activities, and Conditional Gateways.
- A Human Activity is a BPT step assigned to a user or role that appears in the user's Taskbox; the process advances only when the user opens and submits the task.
- LogMessage is the built-in action for writing structured application log entries visible in Service Center, separate from the automatic logging the platform performs for unhandled exceptions.
- Common built-in functions such as GetUserId(), NullIdentifier, GetOwnerRoleId(), and the DateTime family are platform-provided and callable inside Aggregates, expressions, and action flows without custom code.
Quick Answer: Beyond synchronous logic, OutSystems provides four advanced execution mechanisms tested on the Associate exam: Timers (scheduled server-side jobs), BPT processes (long-running stateful workflows), Human Activities (user-task steps inside a BPT process), and a catalog of built-in functions (platform utilities like GetUserId and LogMessage) callable across actions and expressions.
Timers: Scheduled Background Jobs
A Timer in OutSystems is a server-side scheduled job that executes a configured Server Action at set intervals — for example, every night at 2 AM, or every 15 minutes. You define Timers in Service Studio: set the schedule (cron-like expression), pick the Server Action to run, and the platform handles the rest. Timers run as background processes independent of any user session, so they have no UI context and cannot manipulate screen widgets.
Typical Timer use cases include sending batch email notifications, purging or archiving old records, synchronizing data with an external system overnight, and regenerating derived aggregates. A Timer is not a client-side JavaScript setTimeout or setInterval, not a UI stopwatch, and not a query profiler — those concerns live elsewhere. When a Timer's Server Action raises an unhandled exception, the Timer execution aborts and the error is logged in Service Center.
BPT (Business Process Technology) Processes
BPT is OutSystems' built-in workflow engine for long-running, stateful business processes spanning days or weeks. Unlike a single Server Action that runs synchronously and returns, a BPT process persists its state between steps, waiting for external events or human input before advancing. This makes BPT ideal for approval workflows, employee onboarding, loan origination, and any multi-stage operation where the process must remember where it is.
A BPT process is composed of several node types:
| Node Type | Role | Runs As |
|---|---|---|
| Human Activity | A task assigned to a user or role; appears in the Taskbox | Waits for human action |
| Automatic Activity | A Server Action executed when the flow reaches it | Server-side, automatic |
| Wait | Pauses until a condition or timeout is met | Engine-managed pause |
| Conditional Gateway | Branches the flow based on a condition | Decision point |
| Launch | Starts a new process instance | Triggered by an action |
BPT is a runtime execution engine, not a CI/CD pipeline (that is LifeTime) and not a nightly batch script (that is a Timer). The engine executes the logic at runtime, persisting state so the process can resume after a wait or a Human Activity completes.
Human Activities
A Human Activity is the BPT node that requires a person to act. When the process reaches a Human Activity, OutSystems creates a task and assigns it to the specified user or role. That task appears in the assignee's Taskbox — the personal task inbox where users see work waiting. The user opens the task, performs the required action (e.g., reviewing a purchase request and clicking Approve), and submits. On submission, the process advances to the next node.
Human Activities are not test-automation steps (BDD Framework handles that), not touch/gesture UI input (widget-level), and not AI-driven actions (AI integrations use REST or extensions). They are real workflow tasks for real users. The definition includes the screen, the role or user assignment, and the output parameters that feed the next step.
LogMessage Built-in Action
LogMessage is the built-in action for writing structured log entries to the OutSystems logging system. You call it inside a Server Action (often in an Exception Handler) to record application-specific events: a failed REST call, a business rule violation, a milestone reached. The entries appear in Service Center under the application's log, filterable by message, severity, and timestamp.
LogMessage is distinct from the platform's automatic exception logging: when an unhandled exception escapes to the top level, OutSystems writes its own error log entry regardless. Calling LogMessage inside an Exception Handler lets you add a controlled, business-meaningful record before you suppress or re-raise the exception. It does not throw, catch, or roll back — it only writes.
Built-in Functions Catalog
OutSystems ships a catalog of built-in functions usable in expressions, Aggregates, and action flows without writing custom code. The exam expects familiarity with the most common ones:
| Function | Returns | Typical Use |
|---|---|---|
GetUserId() | Integer ID of the currently logged-in user | Auditing, filtering by current user |
NullIdentifier | The zero/null identifier value for an entity | Comparisons, default values |
GetOwnerRoleId() | ID of the role that owns the current context | Conditional logic |
GetUserRoles() | List of roles assigned to the current user | Role checks |
Now() / CurrDateTime() | Current server date and time | Timestamps, filters |
NewLine() | Platform-appropriate line break | Building multi-line text |
Length(text) | Character count of a text value | Validation, display logic |
These functions are platform-provided — you do not implement them. Client Actions cannot run Aggregates, but both client and server expressions can use built-in functions that do not require server data access. The exam tests the boundary: functions touching user or session context (GetUserId, GetUserRoles) run server-side; pure functions like Length or NewLine run anywhere.
Common Exam Traps
A recurring trap is conflating Timers with BPT. Timers are scheduled, server-side, stateless between runs. BPT processes are stateful and event-driven. Choose a Timer for nightly batch cleanup; choose BPT for an approval chain that waits for a manager. Another trap is expecting a Human Activity to fire automatically — it requires a human submission. And LogMessage is confused with Raise Exception: LogMessage writes and continues; Raise Exception throws and jumps to a handler.
Which statement correctly describes an OutSystems Timer?
In an OutSystems BPT process, what happens when the flow reaches a Human Activity node?
Which built-in action writes a structured log entry to Service Center and continues executing the handler flow without throwing or rolling back?