Understand system-generated pages

When you create a new custom object in the Skedulo Pulse platform, a set of default templates and configurations are generated by the system.


The system-generated templates for custom objects are built upon the following templates:

  • base-recordcreate
  • base-recordedit
  • base-recordview
  • base-column-editor
  • base-related-listview
  • base-listview

These templates are used as a base, which you can then extend, or override by adding or modifying components in the header, body, or footer blocks. You can add anything from the component library to these blocks.


Template inheritance makes it easy to reuse templates. In the default templates, “blocks” are defined that child templates can override. The inheritance chain can be as long as you like. You leverage inheritance with the extends and block tags.

For example, when you view the default -create template for the Arcade Games object, it will look like this:

{% extends "arcade-games-create" %}

{% set resource_name="Arcade-Games" %}
{% set validation_schema="ArcadeGamesCreate" %}

The extends tag tells Skedulo which template to inherit the properties from, the set resource_name tag defines the name of the resouce, and the set validation_schema tag defines the validation schema.


A resource is a definition of where data can be stored and accessed. It provides the platform with a standard interface of reading and writing data.

  • A unique ID
  • A unique name
  • A schema

With this basic abstraction we can form a contract between data consumers and the mapping layer allowing them to communicate freely with a common understanding of which data objects they are referring to.

The data schema

A data schema is bound to a resource and defines the shape of the data.

The sole purpose of a data schema is to outline the fields and types available on a resource. With this in place not only do we have an understanding of what objects can be queried, but also the fields and types that exist within them.

Note that a data schema is only responsible for holding information on the data, whilst neglecting anything to do with validation or display.

The validation schema

A validation schema is a configuration that contains:

  • A name describing an action it will be responsible for validating. E.g. “CreateJob”, “EditJob”.
  • A JSON schema document outlining the fields and related validation rules to be checked for the related action.

The query API can be made aware (both optionally or forcefully) of any validation schema and can validate any given request before proceeding.

As part of the default offering the following validation schemas are generated for each resource created (where X is the resource name):

  • XEdit
  • XCreate

A validation schema can be automatically generated from any given data schema as well as managed by an API. This means that any resource or schema changes will be automatically reflected, while also allowing manual intervention or management via API or UI such as the phoenix web application.

It’s important to note that while resources will generally have validation schemas related to them, a validation schema isn’t actually tied to a resource. This means that a resource may have 0 to many validation schemas, and that we can re-use this validation logic in many use-cases across the platform. For example:

  • Validating incoming data when initiating a flow.
  • Validating input options when adding a component to a page in page builder.