We recently held a webinar on embedded workflow builder and demonstrated how it can be used to enable your customers to build their own workflows (simplified integrations).
Here is lightly edited transcript of the Q&A. Answers are provided by webinar hosts Gina Lockwood and Jake Hagle.
Question: It appears that [the demo example notification] is going to a general Slack channel. Could the message be directed to an individual Slack user?
Answer: I think that's really the beauty of the embedded workflow builder. You can let your customers dial it in for exactly how they want it to operate. It could be sent to a team channel because maybe multiple people in that team need to know that those files exist and that there's some action that needs to be taken. But it could be that nobody else in my company cares. It's just a DM that I should get. So I could dial that in to just send me direct messages and really customize the workflow for my particular needs.
Question: Who do you see as typically successful with the embedded workflow builder? What skills or personas do you usually work with?
Answer: It's anyone who is determined enough to build something. I think we've seen a really big increase over the last few years of the idea of workflow automation and customer empowerment. So what we've targeted with our embedded workflow builder is really that general case of you're not a developer, you may be technical, but you don't write code. You understand business processes and events, maybe have a rough idea of what APIs look like, but beyond that it's your average skill set.
Those types of people can be extremely successful with the embedded workflow builder. Anyone who needs to customize their business processes can do so in a really simple way.
If you're a RevOps user, for example. A lot of our customers that are in that CRM sales space; they have RevOps teams that are building in workflow builders and other systems like Salesforce. But rather than forcing them to go to another tool, you can give them those controls natively in your app for the type of work that they're already doing.
So I always recommend that you think through who your users are, think through what the power users are trying to do. What are some of the common asks that your team gets: “Hey, it'd be really great if X could do Y.” And that'll really inform where to start as you're envisioning the direction that you could take the embedded workflow builder.
The great thing is you can roll this out in a phased approach. Everything in Prismatic is customer-centric. So you can choose exactly which customers actually have access to the embedded workflow builder before you open it up to the world.
Question: Do you really see end users making their own flows, or is it more the IT or dev type user who does it for the company?
Answer: It's both. It's everyone across the spectrum of technical capability. What we wanted to accomplish with the embedded workflow builder is to reduce that barrier to entry for users who need to be able to build out their own bespoke workflows.
So yeah, we do see some IT or dev-type users who want to build out flows using something like embedded workflow builder. But we also see members of the marketing team who want to just build out workflows for their own processes. So it really is all across the spectrum.
Question: If I were to build an integration as a B2B software company, what would be the advantage of using the embedded builder approach over regular Prismatic integrations?
Answer: What we see most of our customers do is build out the handful of integrations that are core to your product. The other tools that your customers use that are a part of that ecosystem. Build really strong integrations to those that are one-click activated, simple to get started, standard productized integrations. Build it once, deploy to many customers.
In addition to that, there is the entire long tail of systems that may be bespoke to certain customers, those one-off customer requests that often don't get prioritized because maybe that customer just isn't of a high enough value to justify the engineering resources. Let them actually build out their own workflows and have a two-pronged approach to cover the 80 to 90% with that productized set of integrations and then let that long tail be filled by the embedded workflow builder.
Question: (Second part of the above question) Is it possible to do this without exposing my client to Prismatic or making them have an account in Prismatic?
Answer: Absolutely. In the exact same way that Prismatic has a white-labeled, embedded marketplace that your customers can activate for productized integrations you've built on the platform, you can also give them that same kind of white-labeled access to the builder natively in your application.
They don't have to authenticate to Prismatic. They don't even have to know Prismatic's involved. From their perspective, that's just a new feature set that you've rolled out that enables them to build any of their own workflows with the guardrails that you put in place. What actions and connectors do I want available? Should there be specific connectors that need to be used in those workflows? Put those guardrails in place and let them run with it.
Question: If I build a new connector for a platform that's not in your library, can I make that available to other users?
Answer: Absolutely. So within the embedded workflow builder, you have access to Prismatic's public library of connectors, but you also have access to the SDK that Prismatic’s team develops those connectors with. So you can extend the platform into your vertical, add any type of systems that might not be available, including bespoke one-off connectors to customer systems.
And from there, you can control exactly which customers have access to those connectors, whether it's in the embedded workflow builder or any productized integrations you develop using them.
Question: If you embed a white-label builder, where do you suggest putting help in documentation for users?
Answer: We have the ability for you to actually white-label our documentation as well to give your customers a native feeling documentation based on Prismatic standard docs that you can tailor to your look and feel, as well as the built-in help and documentation for all of the connectors that are available to be embedded within your platform.
So you do have the combination of in-app documentation that can be white-labeled, as well as documentation from the Prismatic docs site that you can white label and add as well.
Question: Can a workflow built by a customer be deployed to an instance? Can customers do this themselves, or would we need to handle it for them?
Answer: That's one of our biggest changes with the embedded workflow builder. Now, rather than customers having to actually deploy instances themselves, it's a simple enable button that they can flip on and off to activate that workflow. So your team doesn't have to be involved whatsoever. It is completely self-serve and native to that experience.
For the full context of this Q&A, check out our embedded workflow builder webinar. To see how Prismatic can help you enhance your integration strategy with our embedded workflow builder, schedule a demo.
