Learn Mokapen

Automations

Automations connect a trigger event (something that happens in the CRM, a form submission, an inbound email, or a scheduled time) to a sequence of steps that Mokapen runs on your behalf: create a task, update a deal, send an email, read rows from a Google Sheet, repeat the same operation on dozens of contacts. You configure the flow once, activate it, and the system repeats it whenever the conditions are met.

The full module is included in the Premium Large plan. You find it from the user menu (profile icon at the top right) → Automations: list of flows, visual editor, and execution history.

Overview

Every automation has three main elements:

• Trigger (start) — defines when the flow starts: e.g. "contact form received", "deal modified", "every Monday at 9:00".
• Flow steps — actions in sequence: create or edit records, send messages, wait, check a condition, repeat over a list.
• General settings — title, Owner, Collaborators, Active or Inactive status (the same labels you see in the table).

When the trigger fires, Mokapen queues the run and processes it in the background. Every start leaves a searchable history, step by step, so you can see what succeeded and where to fix things. Automations do not replace human judgment on complex cases: they remove repetitive work and keep the processes you decided on once aligned.

Basic concepts

Before building a flow, it helps to get oriented with the terms you find in the editor:

• Automation / flow — the entire process, from the start block at the top to the last action.
• Block — each box in the editor: start, action, condition, delay, or "ForEach Loop".
• Branch — under a condition or loop, steps can sit on different paths (e.g. "if the condition is met" / "otherwise").
• Variable — a piece of data picked up on the fly: field from the form just submitted, name of the contact that triggered the flow, email of the automation Owner, result of the previous step. Avoids retyping information already in the CRM.
• Owner (list column) — the user under whom Mokapen runs the flow: permissions, email/SMS sending, and record creation depend on them. This is different from the owner of a single task you create in a step: in the flow you can set both, but the automation Owner should have the rights needed for everything the flow must do.
• Collaborators — other users or teams who can view and edit the automation besides the Owner; organization administrators always see everything.

Role in the CRM

Automations connect CRM areas that would otherwise stay separate:

• Marketing and leads — site form → new contact and deal → qualification task → email to the sales rep (Contacts, Deals).
• Operations — deal won → onboarding task → checklist items checked (Tasks, Checklist).
• Support — ticket opened or inbound email → assignment, tags, internal task (Tickets).
• Integrations — periodic read from Google Sheet, Excel online, or web page to align directories (Integrations).
• Commercial documents — updating quote or order line items from a list (Quotes, Orders).

When a step creates tasks, contacts, or tickets, link Connections and Tags as you would manually: generated records stay navigable from the rest of the workspace.

Use cases

• Website leads — "Contact form received" → Create Contact + Create Deal in the Inbound pipeline → Create Task "First contact within 24 hours" → Send Email to the sales rep on duty.
• Sales follow-up — "Deal Modified" only when the stage changes → Create follow-up task with due date derived from the deal expected close date.
• Support SLA — "Ticket Created" → Condition on priority → if high, Send SMS to the contact person and Create linked internal task.
• Weekly summary — scheduled trigger every Monday → Get tasks (with filters) → Send Email summary to the flow Collaborators.
• Directory alignment — nightly scheduled trigger → Read Google Sheet → ForEach Loop over each row → Create or Edit Contact / Company.
• Inbound email — message to dedicated address → save sender → Create ticket linked to the customer.

Automate only processes with clear rules. If every case needs human judgment, limit yourself to preparing the right task with title, due date, and links already filled in.

Access and permissions

Plan — Premium Large is required; without a suitable plan the Automations menu item stays disabled.

Who can create a new one — only the Organization Owner (role described in the Roles guide) can start creation: choose the trigger and save the first flow. Other authorized users can open, edit, or duplicate existing automations if they are Owner or Collaborators of that flow, or if they are organization administrators.

Who sees what in the list — administrators see all organization automations; other users see only those where they are Owner, Collaborator, or member of a team listed among Collaborators.

Who "runs" the flow — Mokapen executes steps with the permissions of the Owner set on the automation (table column). If that person cannot create deals, send email on behalf of the org, or edit tickets, the corresponding step will error: assign as Owner a user who already has the necessary rights, or ask to adjust the role (also in the Roles guide).

List page

In Automations → My Automations you find the table of flows you can access:

• Automation — title and subtitle with the trigger type.
• Type — Event or Scheduled.
• Owner and Collaborators — who manages the flow.
• Status — Active or Inactive.
• Updated on — last change to the flow.

In the sidebar: + Create Automation (Organization Owner only) and link to the list. Selecting multiple rows you can bulk-change Owner, Collaborators, and status, duplicate, or delete (bulk delete is reserved for profiles with advanced edit permissions). Click the title to open the flow card; from there you enter the editor or execution history.

Triggers: overview

The trigger is always the first block of the flow. Choose the type based on when the process should start:

• Event — something happens in the CRM or on a connected channel (form, record modified, email received…).
• Scheduled — Mokapen starts the flow at fixed intervals or on specific dates/times, without user action.

When first created, the automation is Inactive: you can complete all steps calmly and activate it only when ready. Every trigger provides variables (form fields, data from the involved record, etc.) to use in later steps.

Event triggers

They start when something concrete happens. The most used:

• Contact form received — someone fills out a Mokapen form linked to your organization.
• Record created or modified — task, project, appointment, booking, contact, company, deal, ticket, quote, order, product, service, document (exact entries appear on the "Select Trigger" screen with titles like "Task Created", "Contact Modified", "Deal Created"…).
• Inbound email — message received on a dedicated address configured in the organization.

On "modified" and "created" triggers you can add trigger conditions in the configuration panel: these are not the flow Condition step, but filters that decide whether the automation actually starts when the event occurs. Full logic — especially the difference between "field changed" and "current value" — is in Trigger conditions.

These triggers return data from the involved record or form — title, owner, custom fields — ideal for filling automatically generated emails and tasks.

Scheduled triggers

They do not wait for user action; they follow a calendar:

• Fixed schedule — start from a date/time and regular repetition (every hour, every day, every week, every month, every year, or a single run on a specific date).
• Calendar schedule — run on specific calendar days or times (e.g. every Monday at 8:00, on the 2nd of the month).

Mokapen uses the organization time zone. There is no "triggering" record: the flow starts with the settings saved in the trigger. In tests, Mokapen simulates that start immediately, without waiting for the real time.

Examples: monthly reminders to the team, nightly due-date check, periodic sync with an external sheet, combined with filtered Get tasks or Get deals.

Configuring the trigger

In the editor, click the start block at the top to open the configuration panel:

1. Choose the form, record type, or inbound email address (depending on the trigger chosen).
2. For Contact form received, specify the form code (slug) of the correct form: the flow starts only for submissions of that form.
3. For Inbound email, select the dedicated address configured in the organization.
4. For … created or … modified triggers, optionally add the conditions described in the next section.
5. For scheduled triggers, set frequency, day, time, and repetition.
6. Save the automation: settings remain stored even if status is Inactive.

The trigger determines which entries appear in the variable selector of later steps. If you change the start type on an already built flow, check that the variables used still make sense.

Trigger conditions

On … created and … modified triggers (contact, deal, task, ticket, etc.) the start panel includes a conditions section with the same filter and operator interface described in Filters and operators. Here however the rules apply before any flow step starts: if they are not met, the automation is not queued (no execution history appears for that event).

Trigger conditions vs Condition step in the flow

• On the trigger — entry filter: "this must happen" for Mokapen to start the flow.
• Condition step — Yes / No fork after the flow has already started: useful for branching (e.g. high amount → email to director, otherwise internal task only).

No conditions set

• … modified — the flow starts on every save of the record, even if you change only a note or a minor field. To avoid too many runs, always filter.
• … created — the flow starts on every new record of that type.

"… modified" trigger — how conditions work (important)

Mokapen compares the record state before and after the save that generated the event. For each condition you set, two checks run in sequence:

1. The chosen field must have been modified in that save — the "before" and "after" values must differ. If you save the record changing something else (e.g. you update only the description) but do not touch the condition field, the trigger does not fire, even if the field already has the value you care about.
2. The new value (the one after the change) must satisfy the operator and value you specified — e.g. pipeline stage Is one of "Won", amount Is greater than 10,000, email Has any value.

In the interface the first column is called Modified field (not just "Field"): it reminds you that Mokapen looks at a real change on that field, not the generic state of the record.

Practical examples — Deal Modified

• Condition: Modified field = Pipeline stage, operator Is one of, value = Won. User moves stage from "Proposal" to "Won" and saves → fires. Moves from "Lost" to "Won" → fires. Changes only the amount leaving stage as it was → does not fire. Stage was already "Won" and saves without changing it → does not fire.
• Condition: Stage Is one of "Won" AND Amount Is greater than 50,000 — both fields must have been modified in that same save and the new values must meet the rules. If you change only the stage, the second condition fails.
• Two conditions linked with OR (OR): only one rule needs to be satisfied (field modified + new value ok) for the trigger to fire.

"Changed from X to Y" operators and history

On modified triggers you can use advanced operators like Changed from X to Y (and others tied to change history): use them when you care about the explicit transition (e.g. stage went from "Proposal" to "Won"), not just "stage is now Won". For the full operator list see Filters and operators.

"… created" trigger — different conditions

Here Mokapen does not compare before/after: the record was just created. Conditions check the values with which the record is created:

• Example: Ticket Created + priority Is one of "High" → fires only if the new ticket already has high priority at creation.
• Example: Contact Created + tag Contains "Website lead" → fires if the contact is born with that tag.

A field does not need to "have been modified": it did not exist before.

Other event triggers

• Contact form received — main filter = form code; does not use the record field condition grid (submitted values are trigger variables).
• Inbound email — choose which dedicated address; the flow starts for messages received on that address.
• Scheduled triggers — no record conditions; they start according to the saved calendar.

Tips

• On "modified", always start from a tight condition (one field + target value) instead of leaving the trigger empty.
• If the flow never starts, check in CRM history that the save really changed the condition field to the expected new value.
• If it starts too often, add AND conditions or move secondary checks to the Condition step inside the flow.

Flow editor

The edit page is a vertical block editor with linked blocks:

• At the top: editable title, Back, link to execution history, Active / Inactive toggle.
• First block: the chosen trigger.
• Below: steps in order — actions, conditions, delays, "ForEach Loop" cycles.
• + Add action opens the full catalog (same names you see in the editor menus).

Every block can be edited, duplicated, or deleted. Conditions and "ForEach Loop" open branches: add steps on the right branch ("yes" / "no" for conditions, "inside the loop" for repetitions).

On save Mokapen checks required fields and flags dangerous loops between different automations (e.g. flow A triggers B which calls A). In that case save is blocked and the list of involved automations appears.

Available actions

Click + Add action to open the catalog: each entry has the same name you see in Mokapen. After choosing, you fill the modal (reference record, fields to set, message recipient…). Almost every field accepts fixed text or a variable from the menu or dedicated selector.

Below you find all actions currently available, grouped by type. Names in bold are catalog names.

Before the catalog, read How to fill action modals: it explains record ID fields, single vs multiple values, and filters with operators (also useful for Get … and Condition).

How to fill action modals

Almost every action opens a modal with fields to fill. Some always appear, others only if you add a field from the list. Here is what you need to know to avoid mistakes on first save.

Which record to work on: the ID field

For Read …, Edit …, Clone …, Get connections, Update checklist, Get quote items / Get order items, and similar, you must indicate which CRM record to use. At the top of the modal appears a field with the exact record type label, for example Contact ID, Deal ID, Task ID, Ticket ID — the same name you see when opening the record in the CRM.

• You can paste a fixed ID number (for testing only) or, in the vast majority of cases, select a variable from the selector (icon next to the field or "/" key): e.g. the ID of the contact created by the previous step, the ID of the deal that triggered the flow, the ID read with a Read Deal step.
• This field accepts one value only — one variable or one ID. Do not enter multiple IDs separated by commas and do not select multiple variable badges in the same field: Mokapen must know exactly one record to read or edit.
• If the field stays empty or the variable does not contain a valid ID, the step fails in execution history with a required field error.

Single value, multiple values, and connections

Not all fields behave the same when filling a create or edit action:

• Single fields — title, owner, a date, an amount, email, phone, pipeline stage, etc.: you must provide one value (fixed text or a variable). If the variable is a list (array), Mokapen cannot use it in a field that accepts only one: choose a "simple" variable or a specific field from the previous step.
• Connection fields — fields whose name starts with connected_ (e.g. connected contacts, connected deal, connected company): can contain multiple records. Next to the field you often see Add or Replace: with Add new connections are added to those already on the record; with Replace current connections are removed and only those you specify remain. You can set them with one or more IDs, multiple variables, or output from Get connections.
• Other multi-value fields — tags, stakeholders, some lists: accept multiple entries; the variable selector may show a "?" icon on the badge: hover to see if the variable is plain text, date, multi list, etc.

In Edit … actions only fields you add with Add field appear: you do not need to fill the entire record, just ID + the fields you want to change.

Creating a new record

These actions generate a new record in the organization, as if you created it manually from list or record. Fill title, owner, links, and custom fields; you can prefill them with trigger or previous-step variables.

• Create Task — opens an activity (due date, owner, priority, connections to customer or deal). Typical after a lead or for automatic follow-ups.
• Create Project — starts an operational project linked to the customer or process that triggered the flow.
• Create Appointment — adds a calendar commitment (call, visit, review).
• Create Booking — registers a bookable slot linked to your services or resources.
• Create Contact — adds a person to the directory (from form, external sheet, inbound email).
• Create Company — adds a company to the directory, often paired with the contact created in the same flow.
• Create Deal — opens a deal in the pipeline (amount, stage, linked contact or company).
• Create Ticket — opens a support request already associated with the customer.
• Create Quote — generates a commercial document with lines, totals, and customer data.
• Create Order — records a confirmed order, often after a won deal or accepted quote.
• Create Product — adds an item to the product catalog.
• Create Service — adds an item to the service catalog.
• Create Document — archives a structured document in the organization documents area.

Reading an existing record

These actions load a single record already in the CRM. In the modal fill the ID … field (e.g. Contact ID) with the variable pointing to the right record, then save. Fields from the read record become variables available to later steps with the step name (e.g. title and email of the contact read at step 3).

Use them when the trigger is not enough — e.g. you need to read the amount of a linked deal that did not trigger the flow — or when you must update a different record from the start.

• Read Contact — retrieves name, email, phone, custom fields, and other contact data.
• Read Company — retrieves company name, VAT number, address, and company fields.
• Read Task — reads title, due date, status, owner, and task fields.
• Read Project — retrieves project data and status.
• Read Appointment — reads date, time, participants, and appointment notes.
• Read Booking — retrieves slot, service, and booking data.
• Read Deal — reads amount, pipeline stage, probability, dates, and commercial fields.
• Read Ticket — retrieves priority, status, description, and ticket assignments.
• Read Quote — reads header, totals, and quote metadata (not lines: for those use Get quote items).
• Read Order — retrieves order data (header; lines are handled with Get order items).
• Read Product — reads price, code, description, and catalog product fields.
• Read Service — retrieves catalog service data.
• Read Document — reads title, type, and archived document fields.
• Read user or team — retrieves data of an organization user or team (name, email, role…) for use in emails or assignments.

Editing an existing record

These actions update fields on an existing record. In the modal: (1) specify ID … of the record to edit; (2) add with Add field only the fields you want to change; (3) for each field enter fixed value or variable. On connections and multi-value lists remember Add / Replace (see How to fill action modals).

• Edit Contact — updates directory, tags, custom fields, or contact owner.
• Edit Company — changes company data, classifications, or company fields.
• Edit Task — moves due date, status, owner, or task description.
• Edit Project — updates status, dates, or project fields.
• Edit Appointment — changes time, title, or appointment participants.
• Edit Booking — updates slot or booking data.
• Edit Deal — moves stage, amount, probability, or other commercial fields.
• Edit Ticket — changes status, priority, assignment, or ticket fields.
• Edit Quote — updates quote header and fields (line items have dedicated actions).
• Edit Order — updates order header and fields.
• Edit Product — changes price, code, or product attributes.
• Edit Service — updates catalog service data.
• Edit Document — modifies title, classification, or document fields.

Cloning an existing record

These actions create a copy of an existing record. In the modal specify the ID … of the source record (variable or fixed ID) and, where provided, duplication options (checklist, attachments, connections). The new duplicated record exposes a new ID usable in later steps.

• Clone Task — copies a task keeping chosen structure and links.
• Clone Project — replicates a template project for a new customer or cycle.
• Clone Appointment — creates a twin appointment with date or participants to adjust.
• Clone Booking — copies a template booking.
• Clone Contact — creates a derived contact (variant, branch, additional contact person).
• Clone Company — copies a template company.
• Clone Deal — duplicates a deal for renewal or upsell.
• Clone Ticket — reopens a similar case starting from an existing ticket.
• Clone Product — creates a catalog product variant.
• Clone Service — copies a template service.
• Clone Document — replicates a structured document.

The catalog does not include Clone Quote or Clone Order: for commercial documents use Create Quote / Create Order or duplicate manually from the record in the CRM.

Getting lists of records

Actions Get tasks, Get Contacts, Get deals, and others in the same family do not ask for a single ID: they search for multiple records in the organization and return a list. In the modal you find:

• Filters (optional) — section at the top with the same logic as CRM reports and conditions. Without filters the action may return many rows (up to the internal limit): always narrow criteria in production.
• Button to add a condition: for each row choose field (from the entity field list), operator (depends on field type — see Filters and operators), and value (text, date, status, variable…).
• Between one condition and the next choose AND (AND — both must be true) or OR (OR — only one needs to be true).

What you get after execution

• results — array of records matching the filters; each element contains the entity fields (ID, title, owner, custom fields…).
• total — number of records found.

To act on each row of the list add right after the step a ForEach Loop and connect the results variable from the Get … step. Inside the loop each action "sees" the current record (contact, task, etc.) as if it were the trigger.

• Get tasks — filtered task list (e.g. due tomorrow, sales team, status "Open").
• Get projects — projects matching chosen criteria.
• Get Contacts — filtered contacts (e.g. with tag "Newsletter", created in the last week).
• Get companies — companies by sector, tag, or other filters.
• Get deals — deals by stage, amount, or pipeline.
• Get appointments — appointments in a range or with certain characteristics.
• Get bookings — filtered bookings.
• Get tickets — tickets by status, priority, or assignment.
• Get products — catalog products matching filters.
• Get services — filtered catalog services.
• Get documents — archived documents according to set criteria.
• Get users — organization users (e.g. for summary notifications).
• Get team users — members of a specific team (filter by team in conditions).

There are no Get quotes or Get orders as lists of document headers: for quote and order lines use the actions in the next section.

Filters and operators (Get lists and Conditions)

Operators appear in the dropdown next to each condition in three contexts: Get … actions, flow Condition step, and trigger conditions (… created / … modified). Mokapen shows only operators compatible with the chosen field type (text, number, date, list, yes/no). On modified triggers, besides the operator, the field must have actually changed in that save — see Trigger conditions.

Text and generic fields

• Is equal to — the field matches the value exactly (e.g. country = "Italy").
• Is not equal to — the field differs from the specified value.
• Contains — the text includes the substring (e.g. email contains "@company.com").
• Does not contain — the text does not include the substring.
• Starts with / Ends with — useful for code prefixes or domain suffixes.
• Has any value — the field is filled (not empty).
• Has no value — the field is empty or absent.
• Is one of / Is not one of — the value belongs (or not) to a list of chosen options.
• Is equal to every / Is not equal to every, Contains every / Does not contain every — for fields that can have multiple values: checks that all specified values are present (or absent).

Numbers and amounts

• Is equal to, Is not equal to — exact comparison.
• Is less than, Is less than or equal to, Is greater than, Is greater than or equal to — typical comparisons on amounts, quantities, scores.
• Is between — numeric range (minimum and maximum value).
• Has any value, Has no value, and "one of" / "every" operators also apply where relevant.

Dates and due dates

• Is equal to, Is before, Is after — comparison with a specific date.
• Is between / Is not between — date range.
• Is within X days/hours/minutes/weeks/months from now — window relative to today (e.g. due within 7 days).
• Is more than X days/hours/minutes ago — event that happened at least X time units ago.
• Is exactly X days/hours from now — date at fixed distance from today.
• Is in the past / Is in the future — without entering a fixed date.

List, status, tags, connections (choice fields)

• Is one of / Is not one of — the record has (or not) at least one of the selected values (pipeline stage, ticket priority, tag…).
• Contains every / Does not contain every — all chosen values must be present (or absent) in the multi-value field.

Advanced operators (change history)

These appear mainly in Condition on "record modified" triggers and, where the field type allows, also in Get … filters. They compare the value before and after the change or verify recent updates:

• Has ever been equal to / Has never been equal to, Has ever been one of / Has never been one of — field history over time.
• Updated in the last X days / Not updated in the last X days — the field changed (or not) recently.
• Changed from X to Y — the value went from one specific value to another (useful on deal modify trigger: "stage was Proposal and became Won").

After choosing the operator, open the value row (arrow icon) if needed: for relative dates enter only the number X; for Has any value / Has no value no value is required.

Quote and order line items

These actions work on the line items table inside a quote or order (products, quantities, prices), not on the document header. For Get quote items / Get order items and Edit quote items / Edit order items specify Quote ID or Order ID (trigger variable or from a Read/Create Quote|Order step).

• Get quote items — reads all lines of an existing quote, to use in a ForEach Loop or edit steps.
• Get order items — retrieves lines of an existing order.
• Edit quote items — updates lines with three modes: Replace all line items, Append line items, or Update matching line items only (with matching criterion and fields to update).
• Edit order items — same purpose on order lines, with the same modes.

These are advanced actions: try them on test quotes and orders and check execution history line by line.

Connections and checklist

Get connections

Retrieves linked records to a record (contacts, deals, tasks, companies… linked to the same entity), without opening them one by one in the CRM.

In the modal

1. Choose Type — which "central" record you are considering (Contact, Deal, Task, Ticket…).
2. Fill the corresponding ID … field (e.g. Contact ID) with a variable: usually the trigger ID or from a Read … / Create … step.
3. Save the action.

What you get — variables for each connection type, for example the full list connected_contacts, linked IDs (connected_contacts.contact_id), titles (connected_contacts.title), and the same schema for deals, companies, tasks, etc. These are multi-value variables: use them in a ForEach Loop on IDs, or in connection fields of Edit … / Create … with Add mode.

Update checklist

Modifies a record checklist (customer onboarding, project QA, ticket closure) by checking existing items or adding new ones, without opening the record.

In the modal

1. Type — entity that has the checklist (Task, Deal, Ticket, Contact…; only types that support checklist in Mokapen appear).
2. ID … — variable or ID of the record to update.
3. Add / Replace — Add keeps existing items and appends those you define below; Replace deletes the entire current checklist and inserts only the list you fill in the modal.
4. Checklist — one or more rows: check Done to mark complete, write the title (also with variables, e.g. "Verify {$contact.name}"), add rows with the dedicated button, reorder by dragging.

Rows with empty title are ignored. After execution check the record or step history to verify items were applied.

Communication

Send Email

Sends a real email from the flow. Sending always goes through an SMTP account linked in Mokapen — not from a "generic" address without configuration.

In the modal

• From — select from the list an SMTP address already configured in the organization Email integrations (accounts linked by the automation Owner or users with permission). Alternatively you can specify an address or variable (e.g. flow Owner email): Mokapen will use the SMTP integration associated with that address after resolving variables. If no SMTP account matches, the step fails — a yellow warning appears under the From field.
• If you are a Collaborator and not the flow Owner, the Owner must have the sending email connected; otherwise sending will not start.
• To (required), CC, BCC — one or more addresses, comma-separated if needed, or variables (contact email, ticket owner email, etc.).
• Subject and Message — free text with variables; the body uses the full editor (HTML too).

The recipient receives the mail from the chosen SMTP sender. Check spam and domain reputation if mail does not arrive; execution history shows whether the step completed or was rejected.

Send SMS

Sends a short SMS via the LinkMobility integration (Mokapen SMS gateway).

In the modal

• SMS Account — choose one of the SMS accounts linked to the automation Owner (sender alias configured in Integrations → SMS). If the list is empty, link a number/alias first from the integrations page.
• Here too, if you edit the flow as Collaborator, the Owner must have the SMS integration active.
• Template (optional) — select an organization SMS template to prefill the text; you can edit it afterward. Template placeholders are not automatically replaced with contact data: use automation variables in the message.
• Phone — recipient number (international format recommended) or variable (e.g. trigger contact phone).
• Message — SMS text with variables; respect provider length limits.

Verify SMS credits and sender number in Integrations. Flow test sends real SMS.

WhatsApp — in the Automations module today only Send Email and Send SMS are available. WhatsApp (WABA) is usable in CRM conversations and via related integrations, but does not appear as an action in the automation catalog. For automatic WhatsApp messages consider external integrations or manual flows from the inbox.

Flow control

• Delay — pauses the flow for minutes, hours, or days before the next step (reminders, waits between two actions).
• Condition — creates a fork: if the rule on fields or variables is met, Mokapen follows the "yes" branch, otherwise the "no" branch.
• ForEach Loop — repeats steps in the inner branch for each element of a list (typically output of Get Contacts, Get tasks, or rows read from an external sheet).

Reading from forms and external sources

These actions read data outside the single trigger record or integrate lists from files and forms. They require active integrations where indicated (see Integration-linked actions).

Read Form

Action in the catalog to know the field structure of an organization form (same fields defined in the form builder). In practice, when a visitor fills a form, submitted values are already available as variables if you use the Contact form received trigger (form code + field preview in the trigger). Use Read Form in a more complex flow if you need to map technical form field names to contact, deal, or task created in later steps. The form code is the slug visible in the organization page/form configuration.

Read Google Sheet

Imports rows from a Google Sheet accessible via URL.

• First link the Google account in Integrations if the sheet is private or requires authentication.
• In the modal paste the sheet URL in exportable format (e.g. link ending with export?format=csv for public or shared CSV).
• Leave the URL field and wait for the File loaded message: Mokapen downloads the file, detects columns (CSV, JSON, or Excel), and shows preview in the result tab.
• Output — results variables (array of rows, one per sheet row) and total (count). Each column becomes a field accessible inside ForEach Loop (e.g. map "Email" column to Create Contact → email).

Read Excel online

Same interface as Read Google Sheet, designed for Microsoft 365 files (OneDrive, SharePoint, direct link to .xlsx/.xls).

• Link Microsoft Office 365 in Integrations if the file requires Microsoft login.
• Paste the file or sharing link URL, wait for loading.
• Use results + ForEach Loop to sync rows with contacts, products, or deals in the CRM.

Read from URL

Generic read from web address: CSV, JSON, Excel online, or APIs returning tabular data.

• Enter the full URL (https://…). Format is detected automatically.
• If the URL is unreachable, protected, or returns an error, a red warning appears and the step fails on execution.
• After loading, detected columns are available as step variables; combine with ForEach Loop for bulk imports or updates from external systems.

For all three URL actions: save the action only after successful loading in edit mode, so columns stay stored. If you change URL, reload and verify preview before activating the flow.

Conditions, delays, and "ForEach Loop"

Deep dive on the three steps that do not create records but steer the flow:

The Condition action creates a Yes / No fork. Add one or more rules with the same interface described in Filters and operators: field (or variable), operator, value, AND/OR links. Examples: "deal amount is greater than 10,000", "contact email has any value", "stage changed from Proposal to Won" (operator Changed from X to Y on modify trigger). Avoid too many nested forks — history becomes hard to follow for a case.

The Delay action pauses the flow before the next step. Combined with dates from variables, it enables reminders ("three days after due date"); in scheduled flows it simply spaces two consecutive actions.

The ForEach Loop action processes a list in bulk: connect output of Get Contacts, Get tasks, or rows from an external sheet; inside the loop each step sees the current element. Design and test on few records first, then scale.

Variables

Variables avoid retyping data already in the CRM or flow. In the editor select from menu or selector with icon — no special syntax to memorize.

Always available

• Organization data (name, settings exposed by the system).
• Owner of the automation data (name, email…).
• Current date and current date and time at execution moment, also with offset (e.g. "today + 7 days" where provided).

From the trigger — depends on chosen start: submitted form fields, values from the record that triggered the flow, inbound email information.

From previous steps — every completed action exposes results to later steps: the identifier (ID …) of the created record, fields from the read contact, the results list from Get deals, sheet columns, the single row inside ForEach Loop. In the variable selector steps are in order: choose the right step, then the field.

Variable types — next to badges, the "?" icon indicates type: plain text, date, number, multi list, user, etc. Respect the destination field type: do not put a "list" variable in a Contact ID field (single value) nor free text where Mokapen expects a numeric ID.

Practical tip: after linking variables, run a test and open step history: verify expected values appear before setting the automation to Active.

Integration-linked actions

Some actions work only if the corresponding integration is active in Integrations and, for email/SMS, if the automation Owner has linked the right account:

• Send Email — SMTP account (Gmail, Outlook, custom SMTP…) associated with the address chosen in the From field. Without valid email integration the step fails.
• Send SMS — LinkMobility / SMS integration with sender alias on the Owner; sufficient credits.
• Read Google Sheet — Google account for private sheets; correct export or sharing URL.
• Read Excel online — Microsoft 365 account for protected OneDrive/SharePoint files.
• Read from URL — no mandatory integration if the address is public; verify the external server responds and accepts the request.

If the connection expires, the step fails in history: reconnect the app from Integrations and repeat the test. For sheets and URLs, map columns and contact or deal fields inside ForEach Loop, as you would in a manual guided alignment.

Testing the flow

From the editor, button for automation test: starts a trial run.

Warning: the test uses the same mechanism as production. Email, SMS, data creation and updates are actually applied. Experiment on test organization or records when the flow is invasive.

Behavior:

• Event trigger — if a run already exists in history, you can reuse that start data; otherwise Mokapen uses settings saved on the trigger.
• Scheduled trigger — simulates immediate start with saved settings, without waiting for the scheduled time.

After queuing open execution history and follow each step. Fix permissions, missing variables, or expired integrations until the run completes.

Execution logs

Every start — automatic, scheduled, or test — generates an entry in history, reachable from the flow card or editor. For each run you see:

• Start time and outcome (in progress, completed, error).
• Start detail — what data the trigger received.
• Detail of each step — what went in, what came out, error messages if any.

The card also shows Flows started in the last 28 days. Older runs are deleted automatically: if you need archive beyond a month, note or export critical cases elsewhere.

Common problems

• Never starts — Active status? Trigger configured? On "modified", the condition requires the indicated field to have changed in that save and the new value to meet the operator (it is not enough that the record already had that value). Repeat a save that really changes that field (e.g. move pipeline stage).
• Step errors on permissions — The automation Owner cannot perform that operation. Change flow Owner or adjust the user role.
• Empty variable — The previous step did not produce the expected data, the ID … field does not point to a valid record, or the flow took the "no" branch of a condition. Check step history before the failed one.
• Save blocked for loop — Two automations trigger each other. Remove the step that calls the other automation or redesign the process.
• Email or SMS not arriving — Spam, SMS credits, org sender, recipient in variables. History shows whether the step completed or was rejected by the provider.
• External integration failed — Expired account, renamed sheet, unreachable address. Reconnect from Integrations and update the step.
• Too many runs — "Modified" trigger without conditions: every save restarts the flow. Add trigger conditions (modified field + value) or move filters to the Condition step.

If history is not enough, Duplicate the automation, try on non-production data, and use test until it is clean.

Form automations (simplified path)

There is a separate path from the full Automations module: on plans that include "Automations from Forms", in the form builder you can link immediate actions — create contact, deal, task, ticket — without opening the flow editor.

Good for landing pages and linear forms. When you need conditions, delays, loops over lists, or read from Google Sheet, switch to the Automations module with "Contact form received" trigger and build the full flow there.

Recommended process

• Design first — On paper: what starts it, which forks, which records or messages it creates. Choose an Owner with sufficient permissions.
• Build as Inactive — Complete trigger and steps, link variables, do not activate immediately.
• Test a real case — Trial run and step-by-step history on controlled data.
• Activate and monitor — Switch to Active; in the first days check history and generated records.
• Update when CRM changes — New pipeline, modified form, reconnected integration: reopen the flow and adjust filters and variables. Duplicate before major changes.
• Clear title and Collaborators — E.g. "Website lead → inbound deal" and sales team among Collaborators: whoever comes later understands the purpose immediately.

Automations, with Connections, Checklist, and Integrations, help Mokapen not only record what happens, but facilitate what should happen — always with history, permissions, and testing before handing off repetitive work.