Skip to main content
All CollectionsUsing Rattle
Rattle No Flow Architecture
Rattle No Flow Architecture

Choose an alternate approach to implementing Rattle at your company.

Nayan Kumar avatar
Written by Nayan Kumar
Updated over 3 months ago

Overview

Rattle No Flow Architecture introduces an alternative approach to how Rattle functions on the backend. This architecture is CRM-agnostic, allowing for seamless data flow across multiple platforms while minimizing the risk of performance issues or disruptions.

Why did we build this?

Rattle’s existing architecture relies on the CRM’s (Salesforce) native Flows functionality. While this delivers the expected outcome, there are certain challenges with this approach:

  • Tight Dependencies: Heavy dependency on the CRM's internal technologies, making it difficult to maintain and add functionality.

  • Performance Issues: CRM native workflows could overload the system, causing slowdowns or even interruptions.

  • Limited Functionality: Each CRM has its own set of limitations, restricting the scope of what we could achieve.

  • Lack of Control: Minimal control over how and when rules were evaluated, which led to inconsistencies.

To overcome these challenges, we developed the No Flow Architecture—our in-house rule engine. This system integrates effortlessly with multiple CRMs, eliminating the complexities and limitations inherent in CRM-specific solutions.

How it works

The No Flow Architecture is designed with simplicity and efficiency in mind. To summarize:

When a workflow is created for a specific object, Rattle pulls only the relevant fields used in the workflow conditions and stores them in our datastore. Every 5 minutes, Rattle performs a periodic data sync to check for any changes in the values of these fields. If a change is detected, the value in the database is updated, and an alert is triggered based on the predefined conditions, sending notifications to Slack or MS Teams.

Rattle uses Salesforce's Bulk API which consumes only a single API call to fetch a large number of records. This would mean:

  • We don’t need to create Flows anymore

  • We don’t need wide ranging permissions anymore

  • Number of API calls will be very limited because BulkAPI is robust

Below is a flowchart explaining how it works:

Supported features

The No Flow architecture supports most features of Rattle although there are a few features that are yet to be supported. Below are the features that are currently supported:

Workflows:

  • General workflows

  • Board, Digest

  • Reports

  • Leaderboard

  • Commands

  • Support Flow

  • Deal Rooms

  • Meetings

  • Meeting Intelligence

  • Atlas

CRMs:

  • HubSpot

  • Salesforce

Messaging Systems:

  • Slack

  • MS Teams

Limitations

While the 'No Flow' Architecture offers a powerful and flexible solution, there are a few limitations to be aware of:

  • Alert Timing: Since the system fetches data periodically (every few minutes), alerts may be delayed by a few minutes.

  • Multiple Changes: If multiple changes occur within a single sleep window (interval between two data pulls) only the latest change will be recognized and trigger an alert.

How to manage this change

Customers can opt-in for the transition to the Rattle No Flow Architecture. Once opted in, Rattle’s engineering team will handle the switch in the backend, deactivating existing Salesforce Flows with no effort required from the customer. After 4 weeks of monitoring to ensure that No Flow works as expected, Rattle will automatically delete the old Flows.

FAQs

  1. How often does the system refresh data?

    1. The refresh interval is typically a few minutes.
      ​

  2. Can the No Flow Architecture be integrated with other CRMs besides HubSpot and Salesforce?

    1. We are continuously working to expand our supported CRMs.
      ​

  3. Will the remaining features be supported in the future?

    1. Yes, we are working on bringing this architecture to parity with all our existing features.​
      ​

  4. What data is stored?

    1. Data for the last 1 year (records that were modified) for the principal object used while creating a workflow is fetched and stored. Field data pulled will be the ones used in the conditions.
      ​
      The first time an object/field is used, a full sync will run that fetches the data/field values. Due to the same, the workflow might not fire in the first run when the field/object is used for the first time (as we do not know the previous value in order to check the difference). It might not fire the first time a workflow is created. It will however fire in the subsequent runs when an incremental sync happens in the case where values change.
      ​

  5. Does Rattle make a full copy of Salesforce data, or only objects referenced in conditions?

    1. Rattle makes a copy of only the objects referenced in conditions.
      ​

  6. Does Rattle also store historical data, or just current values?

    1. Rattle only stores current values.
      ​

  7. Can customers restrict which objects, records, etc. Rattle has access to?

    1. Not currently. Rattle will have access to data based on the permissions that the user that integrates Salesforce has.
      ​

  8. Can customers choose which Rattles use the No Flow Architecture vs. Flow Architecture, or is it all or nothing?

    1. Yes, users can choose which approach to use for each workflow.
      ​

  9. How does this impact other integrations like Clari or Gainsight?

    1. We will eventually migrate other integrations to this approach.
      ​​

  10. What should a customer consider when deciding which architecture to use?

    1. If you’re comfortable with Rattle creating Flows for each workflow, staying on the Flows architecture might be suitable. However, if the volume of Rattle-created Flows is becoming challenging for your Salesforce admin team to manage, we recommend switching to the No Flow Architecture. This system removes the need for individual Flows, simplifying management and reducing the burden on your admin team.
      ​

  11. Can existing workflows be migrated to the new architecture, or do they need to be re-created manually?

    1. They need to be created manually for now. We will work on a migration feature in the near term.
      ​

Did this answer your question?