Getting Started

Beta Feature

RevOps Functions are a limited access beta feature. Please contact your Account Manager if you are interested in joining the beta. The information in this document is a work in progress and is subject to change.

Please provide any questions or feedback to support@revops.io or via your Slack Connect channel if applicable. Additional features and functionality will be added in the future.

This guide will walk you through the process of planning, developing, testing, and releasing custom code powered by RevOps Functions. By leveraging TypeScript (or JavaScript), you can ensure that every aspect of your business is fully automated regardless of it's complexity.

RevOps Functions integrate with various platform features and the specifics of what a function can do will depend on the function type. This guide provides a generic approach to any function type. For specific guidance on a function type, visit RevOps Functions to see the full list of documentation available.

Accessing Functions

Functions can be accessed under the Automate section. Functions can only be managed by users with the administrator role.

Creating Functions

To create a function, visit the functions page and select New Function.

You’ll be able to choose between the various supported function types. Creating a function won’t have any impact on users until you release it.

Creating Multiple Functions per Type

Each function type can have multiple functions created where the results are combined together. This can be a great way to separate different logic such as NDA rules vs Order Form rules.

The exact details on how results are combined is dependent on the function type.

As you had more functions, the total amount of time to execute will increase. We generally recommend a limit of 3-5 functions per type for optimal performance. This recommendation may change depending on the function type and the implementation specifics.

When multiple functions are created, each function’s settings and release cycle are managed separately.

Planning Your Function

Before you can get started with writing your function, you first need to determine your desired outcome and each of the inputs for the function.

Once you’ve determined how you’re going to identify different objects, keep in mind that you will need to update your code if you change these in the future.

Error Handling

Each RevOps function type provides you with the option to determine what happens in the event that the provided code fails to execute. Review the type specific documentation to understand your error handling options.

Pre-Submit Validation Examples

Prevent Mixing Product Tiers

A common use case for validation is to ensure that non-compatible versions of a product aren’t sold together, such as enterprise seat licenses with business add-ons.

In order to prevent mixing product tiers, you first need to identify how you organize your product catalog. Product code schemas are commonly used to group related products or represent the same product across multiple tiers such as business-seats and enterprise seats. In other catalogs, SKUs are grouped by a naming pattern such as User Seats - Enterprise and User Seats - Business.

If you utilize product codes, you can check the product code prefix of each line item while if you have a name pattern, you could check that the string contains the tier name.

Code Example: Product Family Exclusivity

SKU Term Dependency

Certain SKUs have special conditions to them that require a special legal language. For instance, purchasing premium support may require SLA language including uptime credits. Any support SKU cannot be sold without having this term.

Similar to product tiers, products can be identified by a convention to product code or name. They may also be small enough that attributes such as product code, name, or id could be directly listed.

To identify that the support SLA is included, we could reference name, label, or id.

Code Example: SKU and Term Dependency

Contract Duration Policies

New Order and Renewal agreements are commonly only sold for whole year increments.

To implement this rule, we need to reference two separate attributes. This rule only applies to certain agreement types, so agreements of other types shouldn’t check this rule. If the agreement type is right, we need to check the contract length is evenly divisible by 12.

Code Example: Contract Duration Rules

Developing and Testing

Once you've established the validation rules you aim to implement, you're set to move into the development phase. Our Function Examples page is a valuable resource of sample code snippets that you can adapt to suit your specific requirements.

We advise tackling the development process one rule at a time, making good use of the testing facility to evaluate various permutations of both valid and invalid agreements.

Within the functions editor, you'll find a dedicated testing area. Here, you can input a deal ID or the URL of any saved deal to run it through your current validation draft. In addition to testing functionality, this tool also lets you review the specific data associated with that deal. Any modifications made to the deal need to be saved before they can be tested.

Best Practices

• Utilize console.log (or higher) statements to allow you to debug your function when execution isn't matching expectations. We'll provide these logs to you when debugging and to admins during deal submission.
• Test your function across a variety of deal types, including your non-standard agreements to ensure that your function accounts for all scenarios.
• Add comments to help yourself or other editors update your function in the future. In addition to comments helping you understand what the code does, descriptive comments can help you understand the reasons behind why something is happening the way it is.
• Ensure a reasonable number of total functions. more info

Releasing

Changes to your function are managed via releases. Your function won’t have any impact until you release your first version.

After you’ve released your first version, any changes to the function will require a new release. This enables you to maintain a draft of your function to edit and test separately from what impacts users.

Each release allows you to provide release notes. These are notes to your future self and team to highlight what changed between each version (and why). You can always review an old version and compare it with any other.

Enjoy Your Automation

Once you've released your function, it is live and executing! Sit back, relax, and enjoy the time you're saving through automating your processes.