Customer Requests

We're building automated lead intake against your REST API ( api.leadsimple.com/rest ) and hit a gap we'd like to request parity on. The request: Allow setting user roles on deals via the API, the same way it already works for processes. What works today: POST /processes and PUT /processes/{id} accept users_in_roles[][role_id] and users_in_roles[][user_id], and role definitions are discoverable via GET /process_types/{id}/assignee_roles. This works great. The gap: Deals have no equivalent, even though pipelines support the same user roles in the UI (Pipeline Settings → Users & Roles → Add Assignee Role). Specifically: POST /deals and PUT /deals/{deal_id} accept only assignee_id (the Lead Owner). Passing users_in_roles[][role_id] / users_in_roles[][user_id] with valid UUIDs returns 200 but the parameter is silently ignored — no role is assigned and no error is returned. The Deal object in API responses doesn't include user role assignments at all, so they can't be read back either. There's no GET /pipelines/{id}/assignee_roles endpoint to discover which roles a pipeline uses (the process-type equivalent exists). Our use case: We create and update leads in our Landlords pipeline programmatically from our website and phone intake systems. That pipeline has a "Leasing Manager" user role that drives who works the lead, and today it can only be set by hand in the UI. Since roles are global objects shared between pipelines and process types, extending the existing users_in_roles parameter to the deal endpoints would give full parity with what the UI already supports. Requested changes, in priority order: Accept users_in_roles on POST /deals and PUT /deals/{deal_id} (or return a validation error rather than silently dropping it). Include user role assignments in the Deal response body. Add GET /pipelines/{pipeline_id}/assignee_roles. Happy to provide request/response examples from our testing if useful. Thanks for considering it!

Please add a setting that allows administrators to disable the "Skip Task" option for selected users or roles. This will ensure required tasks cannot be skipped and help maintain accountability and process consistency.

Currently, you can set the default outgoing email account at the process level. However, many processes have emails going to different parties that sometimes require different outgoing email accounts to be used. For example, we have an owner's email account that all owner communications go through and a tenant's email account where all tenant communications go through. In our delinquent rent process, for example, we have automated communications that are going to both the owners and the tenants. The current configuration limitations force us to choose a single email account to use for all of those communications. This creates confusion with our owners and tenants because they are being communicated to through multiple channels and they don't know where they should send an email when they need to send one.

Currently, the GET /conversations endpoint returns basic metadata but completely lacks any reference to the process, deal, or contact it belongs to. Example of current response: { "data": [ { "created_at": "2026-05-07T17:30:14Z", "updated_at": "2026-05-07T17:30:14Z", "id": "cb5ff44f-dd63-4ca4-820b-d3df663b78ae", "subject": null, "snippet": null, "link": " https://app.leadsimple.com/v2/inbox/all?inboxFilters=conversationId=S9p360UbNAGUvqWHspCiPjqhKq-RwwLWOeYEM0Y51Sq5YRiJohy_ThPUqZc= ", "kind": "email", "status": "closed", "assigned": false, "inbox": " leasing@ncrentals247.com ", "first_call": null, "first_email": null, "first_text_message": null, "last_activity_at": null } We request an expanded version of this endpoint. Ideally, this could be achieved in one of two ways: Append an array of IDs for related objects directly into the root object of each conversation (similar to how your Data API structures it). Allow an optional query parameter, such as GET /conversations?include=processes, to dynamically inject the related process data. We need the response to include a process_ids array (or a process object) containing the ID(s) of the process linked to each conversation. Without these IDs, it is technically impossible for our external system to know which conversation belongs to which pipeline or workflow inside LeadSimple. Adding these association arrays will allow us to successfully sync and map our communication history automatically. Please let me know if this specification is clear enough for your engineering team to review, or if you need any further technical details

In our experience so far, when an e-signature sits pending in someone's court for too long, it cancels the entire e-signature. This is very inconvenient for our PMA signing process, as sometimes the decision takes longer or certain parties need more time to sign. Is it possible for these to never time out?

In the settings of a stage, we aren't able to use "Any condition is true" and "All conditions are true" at the same time. Its absurd we can just use one or another. Some cases require to have setups like IF (Condition 1 OR Condition 2) AND (Condition 3) then proceed. Or other times setups like IF (Condition 1 AND Condition 2 AND Condition 3) OR (Condition 4 OR Condition 5) then proceed. We should have that conditions limited as they are right now.

It would be incredibly helpful to have font color selection in email templates- even if it is only one color (red?). We need to explain in the template what the user needs to add or attach and hope they remember to delete the instructions before sending to clients. Having it stand out in red font would help the user see it!

Stages to distinguish if a showing is scheduled or no, at least just that

Ability to add a signature at the end of each text.

Please bring back the check offs for emails and texts. We send texts/emails through other systems for documentation/functionality and are being forced to skip each of these tasks now. Commonly we've already communicated things inside the email template and want to document that this is completed, not skipped.