Ship automations as product with Projects

Projects are your way to bring together your recipes and connections in Workato, and turn them into robust automation products that you can develop, ship and maintain, without code.

Projects help you with three key tasks:

Organizing your assets
Controlling access
Managing change

Organize assets

A Workato account might have dozens of recipes and just as many connections out to the different apps you use. Sometimes a recipe might stand on its own, but more commonly you’ll see a group of recipes working together to serve some business purpose. That’s basically a project.

You can organize your assets under projects in any way that makes sense for your organization. You might group them by:

Department – for example, all of your HR automations
Business process – for example, a project to sync order details and status between your CS platforms
Product or service – for example, a group of recipes that create an API portal for retail partners to track the shipping status of orders

As an example, let’s look at a project I’ve created for syncing order details between CS Systems:

This project is simple, with only three recipes:

Create orders in Netsuite when I receive a new order from Shopify
Keep my information in Zendesk up-to-date when I make changes in Netsuite
Allow customers to kick off a return process via a Zendesk ticket

You can see how these three recipes go together. They use a common set of connections, and changes to any one of them could affect the others. So by organizing them this way, I’m setting myself up to create and ship a unified piece of product for dealing with orders, and to be able to maintain and grow that product over time. If I want to make a change: an extra field to my order form, an approval step for large orders, additional analytics, all the affected assets are here.

Control Access

Automation can be valuable to almost every part of the enterprise from IT to Human Resources. As a rule, the more subject matter experts you have active in your automation platform, the more value you’ll see.

On the other hand, a lot of automations are business critical. Finance reports and data syncs have to run on time and they have to run correctly every time. They need to be protected against accidental change from users that don’t fully understand them. Other automations involve sensitive information, like payroll data, that most employees shouldn’t see. For these automations to be valuable you have to be able to control access.

Projects can help you bring in the users you need to realize value, without risking security, by creating roles with project-specific access.

For example, I can create a custom role for my CS Operations Manager. 

I can give this role full access to recipes, connections and folders, but only in my projects related to CS. This way, I give my users all the control they need, without compromising sensitive data that they don’t need.

At any time, I can see a full list of every user with access to each project in the Settings tab.

Change Management

I’ve already talked about turning Workato recipes and connections into product. Let’s look back at my order syncing project:

What I really have here is a software product for managing orders. Even though I haven’t written a line of code, this is still software, and it’s a business critical product that needs to work. If these automations fail, I will:

Increase my costs following up dropped orders
Lose short-term revenue from dropped orders
Lose customer lifetime value by giving customers a poor experience

For this reason, if I need to update these recipes, I don’t want to just make changes and hope I don’t break anything. To protect a business critical product, you need change management. This isn’t just for developers, it’s vital for scaling up any automation. In order to trust a critical process to automation, you have to be able to develop a change, test it safely, and deploy it with zero downtime.

Traditional software development has a whole universe of tools for change and lifecycle management. If you’re using those tools today, Workato can work with them. But to use traditional change management requires developers and DevOps specialists. That isn’t always possible, and even when it is, it can be a major bottleneck. If a subject matter expert can harness their expertise to automate business processes without developers, it would be a shame to have to go back to relying on them to manage change safely.

Introducing Environments

Just like we’ve made it possible to develop automations without using code, our goal is to make robust change management accessible to everyone, as part of our low-code / no-code platform. That’s why in just a few weeks, we’re releasing built-in environments.

If you opt into environments, each Workato workspace will come with three default environments:

A development environment where you can work on building out your recipes.
A test environment, where you can do your quality assurance
A production environment, where you deploy the most recent stable version of your recipes.

In your development and test environments, your connections can link out to sandbox versions of your apps, while in Production, they connect to your real production data. This way, you can safely work on changes to an existing set of recipes, test how they work together as a unit, and deploy them to production when you’re confident that they work as you intended.

You’ll be able to deploy assets from one environment to another, completely inside Workato.

Just click Deploy Project, select your environment, and follow the wizard.

Choose your own workflow

Note that if you already have an established change management process using traditional tools, you don’t need to change it. You can export assets as a JSON manifest, review changes in git, and deploy approved changes to an environment via the Developer API. But you can now choose to create a simple no-code change management process to protect your critical business processes. You can even use a mix of both approaches. For example, use a git-based process, with multiple test environments for your IT projects, and a more lightweight approval process based in the Workato UI for Sales, Marketing and HR projects.

You’ll also be able to give your users environment-specific access. For example, you can give your QA team access to your test environments, but only allow your integration specialists to make changes in production.

You’ll get a detailed deployment log to review, and if there’s a problem you can easily roll back to a previous deployment at any time.

So that’s Projects. They’re a way to bring the right team together, with the right access, to develop and ship automations as product. And to do it with all the procedural rigor that you expect from software development, without the code