A customer recently described their initial use case for InRule Decisioning. At the start of the discussion, the desired implementation included interactions with Snowflake. As the conversation progressed, they expressed an interest in integrating with Salesforce. By the end of the conversation, they clearly envisioned native decisions inside of the Snowflake platform as well.
Problems often surface progressively. This is certainly the case with problems and risks that were never fully understood at the beginning of a project. In fact, avoiding this is nearly impossible simply because projects and priorities can shift and pivot as they progress. After all, humans operate with a limited horizon. That said, it is our responsibility to unpack the risks and take on the challenges once they surface.
Lists are all the rage for ranking topics; however, they are also a basic tool for analyzing problems and opportunities. As a research tool, taking inventory of existing and potential decisioning opportunities allows everyone to survey the automation landscape prior to funding a project. In a future post, I will explore how to do an inventory of decisioning opportunities.
This post focuses on using that inventory to examine the data epicenter of each decision. This lens helps us understand how the decisions fit into a larger ecosystem and give us insight into the decision automation posture as a single dimension.
Where do decisions begin and end?
If a decision is initiated on Salesforce and ends by updating entities within Salesforce, then this decision is largely Salesforce-targeted. Likewise, decisions that are initiated by a Snowflake query and end by updating snowflake data are targeted for Snowflake. These are the easy ones.
Further along the spectrum are “connector-focused” decisions that require a little of this and a little of that. These decisions should probably be stand-alone or deployed independently of a specific platform. Let’s dive deeper into each of these examples.
If a decision is initiated by a Lightning component or an event inside of Salesforce, and the result updates Salesforce entities, this is squarely a decision that benefits from InRule’s Salesforce runtime. This runtime is context-aware of entity relationships and is capable of hydrating large and complex entity structures at ease. Moreover, the runtime’s use of Salesforce APIs is optimized to reduce the load on API call limits imposed by the platform. Now it’s possible that a decision like this might require a little bit of Snowflake data; however, the fact that it begins and ends on the Salesforce platform clearly defines which runtime your project should focus on.
(It should be noted that InRule is equally capable of doing the same for Microsoft Dynamics)
There are cases where decisions require a little of everything. These decisions often cannot be stateless (gathering the data all up front) because they may require progressive amounts of data during execution. In other words, the data footprint is too unpredictable or too large to manage outside of the decision. In this scenario, the most efficient path is to request data from a source at the time it is required. With InRule, our decisions handily reach out to any ODBC or ADO.NET-compliant data source to make this happen when combined with a driver from CDATA, for example, there are over 200 connectivity options. CDATA turns the world into a SQL query and as a result, there isn’t much remaining in the world that we cannot connect to.
Many decisions are lower-level or intended to support larger decisions. They are often very focused and highly performant. These decisions require all of the data up front and do not reach out to another decision. On the InRule platform, these decisions are both powerful and very portable.
It’s worth spending time to consider all of your potential automated decisions now and in the near term. Try modeling what you know about them in DMN – even if it’s simply cursory notes and a couple of inputs. Annotate these models by where they begin and end. Annotate them by platform – Salesforce, Snowflake, Connected, or Stateless. As you think about what you need today, and in the near future, now you have something concrete to share, socialize and build consensus from.