Skip to content

Developer Expectations

This page describes what Lime expects from anyone who builds workflows. Read it before you start building, so you know in advance what Lime can support and what remains your responsibility.

Must vs. should

Each section separates requirements from recommendations:

  • Must — a requirement. Workflows that break these rules may be deactivated by Lime, and Lime cannot help troubleshoot them until they are fixed.
  • Should — a recommendation. You can deviate from it when you have a good reason, but be prepared to explain that reason when the workflow causes a problem.

Each rule links to the page that explains it in detail.

Naming and Structure

Workflows must stay findable and reviewable by people who did not build them.

Must

Should

  • Remove workflows you no longer need instead of leaving inactive copies behind. If a workflow is kept for reference, say so in its sticky note.

Credentials and Secrets

Your Workflows instance comes with a Lime CRM credential built in. Its integration user is a member of the Lime CRM group Users. If your workflows need more limited access than that group allows, move the user into its own Lime CRM group and restrict its access there.

Must

  • Never hardcode credentials, API keys, webhook secrets, or passwords in nodes, expressions, workflow JSON, sticky notes, or node notes. Use named credential references only.
  • If you have a test Lime CRM environment, use a separate credential for it and never point a test workflow at the production credential. See Credential Names and the Security Checklist.
  • Use the Lime CRM nodes for every operation they support. Call the Lime CRM API with the generic HTTP Request node only for operations the nodes do not cover yet. See Always Use the Lime CRM Nodes.
  • Rotate an API key immediately if it has been exposed — pasted in a chat, committed to a repository, or shared with someone who should not have it.
  • Create additional API keys for dedicated integration users, never for personal user accounts, so the workflow does not depend on any single person's access. Put each integration user in its own Lime CRM group, so that its access can be limited to what the workflow needs.

Error Handling

A workflow that fails silently leaves you believing that data is flowing when it is not. Every failure must be visible to someone who can act on it.

Must

  • Every instance has a global Error Trigger workflow, and every production workflow is connected to it. See Layer 3 — Global Workflow Error Trigger.
  • Error logs include enough context to act on: workflow name, execution ID, the Lime CRM record ID involved, and the error message.
  • If the integration must deliver every record, design it to pick up where it left off after an interrupted execution. Executions get interrupted for many reasons: a platform upgrade, a network outage, another workflow consuming the instance's resources, or the other system not responding as expected. Write checkpoints to Lime CRM or to the other system and keep steps re-runnable, so that a re-run completes the work instead of repeating or losing it. See Design for 3rd-Party Unavailability.

Should

  • In business-critical workflows, configure an error output on every node that can fail — Lime CRM operations and external API calls alike — and route it to a logging or alerting step, not a dead end. For less important workflows the global Error Trigger is enough, since the execution log points to the failing node anyway.
  • Design steps so that a failed execution can be re-run without creating duplicates or corrupting data. Use upsert patterns instead of blind creates. See Build for Retries and Failures. An existence check before a create reduces duplicates but does not prevent them when two executions run at the same time, so treat this as damage limitation, not a guarantee.
  • Enable Retry on Fail on every node that calls an external system, with a small retry count and a wait interval.
  • Run through the Error Handling Checklist before activating a workflow in production.

Versioning and Upgrades

Lime upgrades the Workflows platform and the Lime CRM nodes on a regular basis. Backwards-compatible improvements and bug fixes are applied to the nodes already in your workflows, so you get them without doing anything. A breaking change ships as a new node version instead: the nodes already in your workflows stay on the old version until you update them. See Node Versioning.

What Lime does

  • Announces node and platform upgrades, and calls out every breaking change in the release notes.
  • Keeps the previous node version available for a limited period after a breaking change, so that existing workflows keep running while you migrate. How long depends on the reason for the change.

Must

  • Read the release notes when Lime announces an upgrade and assess the impact on the workflows you are responsible for.
  • Test every production workflow after a platform upgrade before assuming it still works.
  • After a breaking change, update the affected nodes in your workflows to the new version before the old version is retired. Lime does not update nodes in your workflows.

Should

  • Know which of your workflows are business-critical, and test those first after an upgrade.
  • Update nodes to a new version in a test workflow first, before changing the production workflow.

Performance and Resource Usage

Workflows run on an instance whose capacity is shared by every workflow on it, and every call to Lime CRM shares your API quota with the rest of your integrations. See Control Performance and Load.

Must

  • Design every workflow and sub-workflow so that a single execution completes within 15 minutes, and split larger workloads into sub-workflows, batches, or scheduled follow-up runs. Long executions block executor slots shared by every workflow on the instance. The workflow timeout setting does not help here, since it cuts the execution off instead of making the work fit. An execution is not guaranteed to get the full 15 minutes, so design it to be resumed as described in Error Handling.
  • Do not fetch all or an excessive number of records. Every Get many operation, such as getManyObjects or getManyUsers, needs a consciously chosen limit and a filter that bounds the result set. Setting the getManyObjects limit to 0 or leaving it empty returns all records, and the default of 50 silently truncates larger result sets. Fetching all records is a deliberate, documented choice.
  • Respect the Lime CRM API rate limit: 3 000 requests per 5 minutes (10 requests per second on average) on Lime Cloud. Design so that one workflow cannot exhaust the quota for the whole instance. Running close to the limit also slows down the people working in the Lime CRM client, since they share the same instance.
  • If you use the Lime CRM bulk nodes on records that have Lime Automations, webhooks, or Python business logic attached, reproduce that logic in a workflow that runs after the bulk job finishes. The bulk nodes bypass the application layer entirely: data is inserted, and no business logic runs.

Should

  • Choose between event-driven triggers, schedule-based polling, or a combination based on what the integration needs. When you poll, poll no more often than the business case actually requires.
  • Use the Lime CRM bulk nodes (bulkCreateManyObjects, bulkUpdateManyObjects) for large data sets (100+ records), preferably where no business logic needs to fire.
  • For workflows that process large volumes of data or are triggered very frequently, set Save successful executions to Do not save in the workflow settings. A full execution log purges the history of your other workflows earlier than you expect, including the ones you need for troubleshooting.
  • Terminate looped sub-workflows with a minimal return node so the parent does not accumulate data across iterations.
  • Keep payloads small: pass record IDs between workflows and fetch the data where it is needed instead of carrying whole objects through every node.

Data Handling and GDPR

Everything a node receives and produces is stored as execution data on the Workflows instance, and everything sent to an external system leaves your control. You are the data controller, and the workflow decides what data actually moves.

Must

  • Send only the fields the integration actually needs to external systems, including AI models and gateways. See Protect Data and Credentials.
  • Do not log full record payloads or personal data in error logs, sticky notes, or dedicated logging Limetypes. Log state transitions and record IDs.
  • Do not send personal data to an external system, including AI providers, unless you have agreed to that system as a processor of your data.
  • Validate and sanitize inbound data from webhooks before writing it to Lime CRM.

Should

  • Remove pinned data that could damage production data if the workflow could be executed manually. Pinned data stays in the workflow definition after you activate the workflow.
  • Keep AI Agent nodes stateless unless the use case is genuinely conversational, and set an explicit session key when memory is used. See Memory for AI Agents.
  • Decide what integration activity is written back into Lime CRM, for example as history notes, so that the data stays visible and auditable where your users expect it.

What Lime Supports and What You Are Responsible For

Lime provides and operates the platform. The workflows built on it belong to whoever built them.

Area Lime You
Workflows instance availability, login, and upgrades Operates and monitors —
Lime CRM nodes and credentials Develops, documents, and fixes defects Reports defects with a minimal reproduction
Documentation in this section Maintains Reads before building
Workflow logic and configuration Builds and maintains workflows in the Managed by Lime project Designs, builds, tests, and maintains own workflows
Error handling, retries, and alerting inside a workflow — Implements and monitors
External systems a workflow talks to — Owns the integration and the relationship with the vendor
Impact assessment and testing after an upgrade Announces changes Assesses and tests own workflows
Data that a workflow moves, logs, or stores — Ensures it matches your agreements

Workflows delivered and maintained by Lime live in the Managed by Lime project of the instance, where you have read-only access. If you need different behaviour, build your own workflow in your project or contact Lime. If you copy a Lime workflow into your project and modify it, the copy is maintained by you like any other workflow there.

When you report a problem, Lime expects a workflow that follows the must rules on this page. If it does not, fixing that is the first step, and it is your step.

Environments and Deployment

Must

  • Before activating a workflow: make sure every credential points to the environment the workflow is meant for, review pinned data, and run through the checklist below.
  • Activate a workflow only when it is ready to run unattended. An active workflow is a production system from the moment the toggle is on.

Should

  • For workflows that write to Lime CRM or an external system, develop and test against a test Lime CRM environment if you have one. If you only have a production environment, test on a small set of records you can clean up afterward.

Checklist Before Activating a Workflow in Production

  • Workflow, nodes, and credentials follow the naming conventions and the workflow is tagged
  • A sticky note describes purpose, trigger, and assumptions
  • No credentials or secrets anywhere in the workflow definition
  • The API key belongs to a dedicated integration user with its own Lime CRM group
  • Lime CRM nodes are used for every operation they support; the HTTP Request node calls the Lime CRM API only where no node covers the operation
  • The global Error Trigger is connected, and in business-critical workflows every failing node routes to a logging or alerting step
  • Error logs include the workflow name, execution ID, record ID, and error message
  • Every Get many operation has a consciously chosen limit and a bounding filter
  • One execution of the workflow and of each sub-workflow completes well within 15 minutes
  • The workflow can be resumed if an execution is interrupted before it finishes, where the integration requires every record to be delivered
  • Where the Lime CRM bulk nodes are used, business logic that would normally fire on the affected records is reproduced in a follow-up workflow
  • Only the fields the integration needs leave Lime CRM, and no personal data is written to logs
  • Pinned data that could damage production data on a manual execution is removed, and all credentials point to production
  • Someone other than the author knows the workflow exists and what to do when it alerts