> For the complete documentation index, see [llms.txt](https://docs.frends.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.frends.com/guides/development/how-to-create-a-shareable-frends-template.md). # How to Create a Shareable Frends Template How to create a template that is easily shared to others. A well-designed template is more than a working Process — it is a reusable starting point that other users can adopt quickly, understand without deep hand-holding, and adapt to their own environment without breaking. This guide walks you through building a template that is easy to share and easy to take into use, whether you publish it in your own tenant, in the Business Automation Portal, or on the public template library at [templates.frends.com](https://templates.frends.com). The key idea is that a template should be easy to take into use. When someone else adopts your template, they should be able to configure it with a handful of clearly named inputs and run it, without reverse-engineering your logic or digging through your tenant's settings. How self-contained a template needs to be, however, depends on where it is published and who takes it into use. This guide explains how to design, build, and package a template for each of the main distribution contexts. ## Prerequisites Before you start, make sure you have the following in place. You need access to a Frends Tenant where you have permission to develop Processes and save Templates, and a clear idea of the integration scenario the template will solve. You should be familiar with the Process Editor, Process Variables, and Environment Variables, as these are the building blocks of a portable template. If you plan to publish the template for a wider audience, decide in advance whether it will be shared within your Tenant, through the Business Automation Portal, or on the public template library. ## Choose where the template will be published How complete and how portable a template needs to be depends on where it will be published and who will take it into use. Frends templates are distributed in three main ways, and each one calls for a different balance between self-containment and Tenant-specific features. A template shared within the same Tenant for your own developers can be more barebones. Because your developers already understand the integration landscape, the Tenant's systems, and its conventions, the template can rely on Tenant-specific features such as Environment Variables, and it does not need to carry every configuration detail. The focus is on giving a solid, consistent starting point rather than on making it fully self-contained. Templates aimed at the Business Automation Portal should be complete out of the box, since business users take them into use without touching the Process Editor. This does not necessarily mean the template must be fully portable across Tenants. In fact, a BAP template may deliberately use more Tenant-specific features to keep it from becoming highly technical for business users. Connection details, credentials, and other technical configuration are better set once in the Tenant by administrators or developers and referenced through Environment Variables, so that business users only see a simple set of guided inputs when they deploy the integration. Public library templates at templates.frends.com are adopted across many different Tenants, so they must be as self-contained and portable as possible. Even here, however, the aimed use case dictates the level of Tenant-specific features that require setup. A template that reads a file from a local fileshare and transforms it can run with nothing more than the Process Variables the user fills in, while a template that connects to a SaaS system may still expect an API credential to be set up in the target Tenant. The point is to be deliberate and explicit about what setup is required, rather than assuming a single level of portability for every public template. Keep these three contexts in mind as you read the sections that follow. Each design decision — how configuration is handled, what to document, and how to tag the template — plays out differently depending on which audience the template serves. ## Design the template before building it A template that is easy to share is designed with its future users in mind. Define the business goal, the source and target systems, the message structures, and the expected inputs and outputs before you open the Process Editor. Decide what the template is responsible for and — just as importantly — what it is not responsible for. A focused template that does one job well is far easier to adopt than a sprawling Process that tries to handle every edge case. Keep the template's responsibility narrow and its flow linear and readable. Avoid combining unrelated actions, transformations, and exception branches into one long flow. Be cautious about extracting logic into Subprocesses: a Subprocess is a separate component, so a template that depends on Subprocesses is no longer self-contained and portable. When someone takes the template into use, any Subprocess it calls must be available in their Tenant as well. For a template that can be shared and adopted on its own, keep the logic inside the template itself rather than relying on external Subprocess dependencies. ## Follow standard input and output formats To make the template as compatible as possible, follow the standard or system-specific default input and output formats for the integration you are building. Use the message structures, file layouts, and field conventions that the source and target systems expect by default, rather than inventing custom ones. When the template reads or writes data, align it with the documented defaults of the connected systems — for example, the standard JSON or XML structure of a particular API, or the expected column layout of a target table. This way the template works out of the box with minimal mapping effort, and users who adopt it in their own environment can rely on well-known formats instead of deciphering proprietary ones. ## Make configuration portable with Process Variables The single most important decision for a template is how you handle configuration values. Environment Variables are convenient because they let each environment hold its own values, but they are always Tenant-specific. When a template travels across Tenants, the person taking it into use may not have your Environment Variables, and the names may not mean anything in their environment. For values that the user of the template needs to provide, use Process Variables instead. Define the key inputs — such as file paths, target addresses, or mapping parameters — as Process Variables initialized in the Process's general parameters. This lets the user fill in the values when they take the template into use, rather than relying on environment-specific settings. This matters most when the template travels across Tenants that do not share your Environment Variables, and it is how templates become executable in the Business Automation Portal, where users input variable values as part of onboarding. For cross-Tenant and public templates, avoid referencing Environment Variables directly. Instead, introduce them through Process Variables: let the user provide values such as credentials and connection points as Process Variables when they take the template into use, and they can then set those values to Environment Variables on their own Tenant. For same-Tenant developer templates and for BAP templates backed by Tenant-level configuration, referencing Environment Variables may be acceptable and preferable, to hide the technical details from business users when onboarding the template in BAP, as described when you chose the publication location. While it makes it easier for the business users to create Processes in BAP from such a template, it does mean someone needs to set it up and configure first in Frends Tenant. In all cases, use secret values for credentials rather than hardcoding them, and prefer the secret fields in Tasks so sensitive values are not logged. A good rule of thumb is that everything the user must choose belongs in a Process Variable, and nothing sensitive belongs in the Process logic itself. ## Include solid error handling A template that fails silently or crashes on the first unexpected input is not easy to take into use. Give the template an agreed, general error handling approach, for example Scope and Catch based handling. When an error occurs, the template should clearly indicate a failed outcome even when custom handling is applied, so that users can tell the difference between a configuration problem and a genuine failure. Distinguish between a failed execution and an error response. A Process that returns a structured error response for invalid input has done its job correctly and should not be marked as a failed execution. Plan recovery step by step: for every important step, define what happens if it fails, whether it can be retried, and how recovery should happen. Use retries for transient failures such as timeouts, not for invalid requests or functional business errors. ## Name things consistently and document the template Consistent naming makes a template understandable at a glance. Use readable, descriptive names for the Process, its Tasks, and its Process Variables. A name like `Import Orders From SFTP To Salesforce` tells the user immediately what the template does, while a stack of variables named `var1`, `var2`, and `var3` leaves them guessing. Document the template as part of the Process itself. Add a description that explains the purpose, the expected inputs, and any assumptions the template makes. Document the required setup thoroughly, so the person adopting the template knows exactly what Tenant-specific configuration they must provide before it can run — state every prerequisite, such as credentials, connection points, target directories, or system access. Document every used and required Environment Variable and Process Variable in order to make the setup as direct as possible. Include operating instructions that cover dependencies, common failure points, recovery actions, and how to test the template before relying on it. This documentation is what lets another user adopt the template without needing you to explain it in person. ## Create the template from your Process Once the Process is designed, built, and tested, turn it into a Template. In the Frends Control Panel, open the Process and select "Update or Create a Template from Process". Set up the general values that identify the template, such as its name, description, and tags. Use tags to signal how much setup the template requires, for example by tagging templates that run out of the box differently from those that need Tenant-level configuration. Because tags also control which organizations can see the template in the Business Automation Portal, aligning them with the required setup helps the right users find and adopt the template. These general values are what show up in the Templates section and in the integration catalog, so make them clear and descriptive. After the template is saved, it appears in the Templates section of the Control Panel, where users in your Tenant can browse it and select it to start a new Process. Before you share it, take the template into use yourself once, from the user's perspective, to confirm that the onboarding steps work and that the Process Variables prompt for the right values. You can learn more about [creating a template from a Process from the reference documentation](/reference/process-development/template.md). ## Share the template and take it into use The distribution context you chose earlier sets how the template is shared. Within your Tenant, the template appears in the Templates section for your developers. In the Business Automation Portal, tags control which organizations see it in the Integration catalog. On the public library at [templates.frends.com](https://templates.frends.com), templates are organized by target system, which makes them easy to discover. When a user takes the template into use, they follow the onboarding steps for the selected template. In the Business Automation Portal, for example, the user opens the Integration catalog, selects the template, gives the new Process a name, and fills in the variable values you defined as Process Variables. They can then execute a trial run in a test environment before deploying the Process to production. Because the template exposes only the inputs the user needs — whether as Process Variables or through Tenant-level configuration set by administrators — onboarding is smooth and requires no knowledge of your original environment. The measure of a good template is how little guidance a new user needs to run it successfully. By keeping the template focused, following standard formats, handling configuration in a way that suits its distribution context, including solid error handling, and documenting it clearly, you create a template that people can find, understand, and take into use on their own. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.frends.com/guides/development/how-to-create-a-shareable-frends-template.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.