The Story of ForeSight

The story of ForeSight is a really interesting example of how a new product is born from an unmet need (necessity is the mother of invention). Back then, Panaya was a super successful player in the ERP market, but the idea of developing a solution for Salesforce was not part of the company’s roadmap.

The journey begins

So how did it all start? The core idea of ForeSight began with a problem that Tal Carmi, one of Panaya’s business applications managers, was facing: Tal was asked to change some of the values in the “Opportunity Stage” picklist in Salesforce. He knew that making this change affects many critical workflows and processes but could not tell exactly which.
When he discussed the problem with Panaya’s CTO, who was always looking for new product directions, the idea was born – why not use Panaya’s capabilities in analyzing the impact of changes on ERP systems for Salesforce? and this is exactly what we did. I was lucky enough to join Panaya at that time and to be part of the team that brought ForeSight to life.

The development process started. We used Salesforce APIs to extract metadata and started the research on how to find mutual influences between components and what is required to provide an impact analysis solution for salesforce. It was an exciting journey. Tal explained each component, and we matched the relevant algorithms. From parsing formulas to AST trees, to finding the picklist values in the context (including the function manipulations – which was the best stuff a geek could wish for 😊), to understanding report types and so much more.

I remember the first time I participated in Dreamforce and presented my work to random Salesforce Admins that I met. Their enthusiasm made me feel like a rockstar!!

During that time at Dreamforce, I first heard about the tooling API. I left everything and immediately wrote back home about the new exciting API (Yes, at the time it was a new API!). When I came back, my team and I started researching and came up with the APEX dependency solution (way before the dependency API, and honestly – much more comprehensive).

Remember Tal, the business applications manager? He was so excited; he joined the team developing the product and became the first product manager! He introduced it to the rest of the business applications team, they used it and absolutely loved it!
The first prototype of ForeSight was born, and we named it ChangeGuru – it almost felt like choosing a name for a newborn “baby”.

We knew we really hit the bullseye right from the first outbound calls we made. Every company we talked to wanted to learn more about the solution, because they were all experiencing the same challenges. Later, when we launched it in Salesforce AppsExchange, it hit several hundred downloads in just a few days.

From prototype to ForeSight

Over the years the product has evolved to a full impact analysis solution for Salesforce, covering almost every major component and showing the full impact of every change. When it was ready, we launched ForeSight. It has been an exciting and thrilling journey – and I know that I might be a little biased – but I think the result is really awesome!

You can read more about the technology behind our dependencies graph in our blog: Graph Animations, Filtering, Dijkstra, and Everything in Between

The concept of co-creating the product with our users was already part of the team’s DNA, and some of the most-used features in the product were conceived by our customers. After all, who knows better than they do what challenges they are facing? I believe that this is our mission: to listen and to keep an open dialogue with our customers, to understand their challenges and find the technological solutions to these challenges. If one of our many customers is facing a problem, there is a probable chance that others have the same problem, and we are here to make their lives easier, by helping them deliver faster and higher-quality results.

I can think about quite a few features that were developed as a result of a specific business problem that one of customers shared with us.

Change is our inspiration

Take for example the free text search – we got the idea for this feature when a customer told us that her company is reorganizing the sales department. In terms of the business, it was not a big change, but from a Salesforce perspective it was a complete nightmare. Different stages in the sales cycle required the approval of senior sales managers, and their names appeared in workflows, and in some cases the names or email addresses of these managers were hard-coded in the system. This customer, who has been using Panaya for quite a few years, is very used to running impact analysis to understand the impact of every change she is making in the org as an Admin, but she had no tool to help her discover in which processes or where in the code the specific names of the people who changed their roles appeared unless she went to the development team for help.

Luckily for us, she immediately thought about Panaya. She presented the problem to her customer success manager, who shared the idea with the product team, and from there the road to introducing the free text search engine was short (Remember the geeks from the beginning of the blog – just give them the opportunity to manipulate big data and they will come up with a creative solution)

A super cool feature with great value that was developed as a result of a need of a customer.

Another great example is our technical debt grid. Unlike the previous examples, it was not created as a direct request from a customer, but we can definitely say that this feature was inspired by our customers. You see, Panaya works with various big enterprise customers with massive orgs that became more and more complex over the years. During our many conversations with these customers, we realized that in many cases they prefer not to delete a field, a process or even a report, when creating a new version of this component. Instead, they add a word that indicates that this is an old component, such as ‘Old’, ‘Archive’, ‘V1’ etc., and keep both versions, just in case. It’s always good to be on the safe side, but as time passes, the accumulation of unused components creates technical debt and slows down Salesforce performance, so this safe side has a price. This challenge seems to repeat itself at many of our customers’ orgs, which led us to develop our technical debt grid. A simple, yet very valuable engine that instantly identifies components that indicate technical debt.

I can think of many other examples. Some of them are big, some of them are small. When our customers see us as partners, everybody wins.

We Want Your Ideas!

So why did I choose to share this story with you? Well, I truly believe that when you listen to customers great things happen! And that is why I wanted to reach out to you.

I sincerely invite you to take part in the ongoing story of ForeSight. Just share your challenges and ideas with us at [email protected]. We promise to read each and every suggestion you send. You might just be the one who sends us the next “Big Idea!”