Why did we build a workflow product that works only with Google Apps?

KiSSFLOW

September 10th, 2012 Google Apps  

Last month, I gave a talk on why we made certain product decisions in KiSSFLOW at Chennai Geeks meetup. Madhuvishy already covered this in great detail in her blog. So, in this blog, I am going to cover the most important decision of all – Why we built KiSSFLOW to be a Google Apps “only” product.

Customer-Vendor structural conflict

There is no doubt that vendors want to create products in the best interest of their customers. But, they are also blinded by their own growth potential. When it comes to choosing between their customer’s interest and their growth potential, they choose the later. Let me give you an example:

Part 1: The elephant in the room is called RBAC

Usually, workflow products expect process owners to define role and assign that role to a workflow step. Users are then mapped to these roles in a separate workflow administration console. Workflow products use this mapping to give users access to the corresponding workflow step. This is the general idea of Role based access control RBAC.

For example, if there is a workflow step called “finance approval”, the process owner has to first define a role called “finance” and then assign “user1” and “user2” to “finance” role. This will give “user1” and “user2” access to “finance approval” workflow step. This has 2 advantages:

  • This way, any user in that role (“user1” & “user2”) can work on the “finance approval” step instead of relying on one user.
  • If a user (“user2”) leaves the company, another user (“user3”) can be added to finance role without having to modify workflow.

But, this concept is difficult for the process owners to understand and managing this user-role mapping is quite tedious.

Now, if you are an email user, you must be wondering, why all this complexity? Email users are comfortable sending emails to email groups (e.g: [email protected]). Emails groups have the same benefit as roles i.e any user in that email group can get access to that workflow step. Why not use that?

The real reason is workflow vendors want their product to be open ended. This allows them to sell their workflow product in many markets. By keeping the role mapping open, they can map roles to email groups in the case of Google Apps or Microsoft ADS or roles in Salesforce.com. It is the customers who bear the cost of this. They spend significant amount of time and money on connectors & integration middleware to integrate workflows with Google Apps or Microsoft ADS or Salesforce.com specific to their IT environment.

With KiSSFLOW, our philosophy has always been about keeping it simple. We weighed both the options and took the customer view – Our product has to be easy-to-use. So, KiSSFLOW uses provisioning API and deeply integrates with Google Apps to map email groups as roles. Therefore, it works only with Google Apps. If that means, we will be able to address only a smaller workflow market ( i.e. Google Apps workflow market) – So be it! We would rather have small number of highly satisfied customers, instead of having a large number of customers who spend countless hours on integration and find that they can’t recover ROI even after years.

If you are a Google Apps customer, you can try it for yourself and see how this decision has simplified workflow creation in KiSSFLOW. I am sure, you will love it!

In the next part, I will talk about the other important advantage of being Google Apps “only” product – Google docs and mail integration. So, stay tuned!