1. Concepts
  2. Template Structure

Concepts

Template Structure

How templates are structured

Overview

Templates are the container for defining a unique process. They are the top-level of any process you define within the Stubber ecosystem.

Following the correct naming conventions for your templates is very important and should be named after the process you are implementing.

Templates have various components and follow a tree-like structure. Let's take a look at the table and image below and break it down. It may look complicated, but it's all really simple.

Component Description
Template The top-level container for the process definition. This is the box on the shelf
that your template lives on in Stubber
Branches Either the draft or live version of your template
Contexts The mode your template is in when its interacted with
A Flow The states and actions of each context within your template
A Layout The visual layout of a flow in the context

NOTE

Together the template, branch and context define a unique process in Stubber. This means that one template can perform several different processes

What is a Context?

The best way to think about context is the "mode" of the template. Some examples of contexts are create, manage or default.

The Create context


The create context (or mode) is where you define what happens when a user first interacts with your template. The create context is primarily used for generating unique stubs. Remember, stubs are the unique instances of your template. Read here if you need a refresher on the relationship between stubs and templates

The Default context


The default context (or mode) is where you define the typical or default flow that should be followed by each stub. This is where you define the process what happens when a customer makes a purchase, or the process of sales enquiry, etc.

The Manage context


The manage context is used to manage all the stubs in the manage context.

Conceptual Example

This means a stub actually follows the definition contained in the context of the template. So there are flows for each context, or mode, within a single template.

Practical Example

Using the sales enquiry example, that template will have several setups for each context. The use case for each context of the sales enquiry might look something like:

  • Create: Specifies what happens when a sales enquiry is created, what information or fields we require, and what actions should be taken to initiate a sales enquiry. We'd likely need some basic customer contact information, what product or service they're interested in, etc. This will be passed over to the Default context when the stub is actually created.
  • Default: The general flow or process that should happen with each sales enquiry that is created. This would be where the process of capturing details, quoting the customer, initiating the sale (or having the sale be rejected) would be defined.
  • Manage: This context specifies how someone would manage a sales enquiry and contains all the actions involved in that process. This context outlines the actions required to oversee and handle the sales enquiry throughout its lifecycle. This could include actions like updating inquiry details, following up with the customer, or closing the enquiry once resolved.

Flow

Basics


The flow is the interface where you actually do the work to set up your templates. This is where you define the states and actions of the the various contexts.

The flow is built and maintained in the Editor application on the Stubber Platform.

States and Actions


The states and actions are the building blocks of the flow. If you require a refresher on states and actions you can visit this page.

Example

Here is an example of what a template structure would look like to define a "sales enquiry" process.

There are 2 default branches namely draft and live.
The publish action on the editor will copy the draft branch to the live branch.

TIP

It is possible to change the program of a stub using the morph stub task.