Steps

A few pieces of terminology:

• Programs in Rhizome are made up of Steps
• Steps have values that can look like any valid JSON
• Blueprints define the shape of those values using Fields
• Workflows can be comprised of a series of Steps

Keys

Keys are key. Steps have to have a key that is unique across the system. If you don't provide a key, one will be generated for you when a Step is created.

• Steps will fail to get created if a duplicate key is used.
• Case sensitivity matters! "Company Name LLC" is not the same key as "company name llc"
• You might want to name keys in ways that make sense to you on sight: e.g. Entity-734de9-Jupiter-Fund-LLC
• In some cases you can edit keys to be different, but you shouldn't do it after $refs are associated.

Blueprints

Blueprints are just Steps without Blueprints of their own, otherwise every Step needs to come from a Blueprint. Programs provide a syntax for creating Step Blueprints in their definition file. (Note that you may also want to create blueprints via JSON API, in certain custom circumstances).

Any time you save a file in a program the definition reruns automatically (via ./bin/watch_programs), so you should see your changes reflected in almost real-time. It also means you'll want to treat your definition as idempotent (in other words, it's expected to run over and over). Basically, you may need to do a pattern where you find and existing Step, or initialize a new one if one doesn't exist, before updating. This kind of concern is largely handled by using the Program definition methods like def_blueprint, but it's important to mention.

Fields

fields is a "magic" named attribute on a Rhizome Blueprint that can provide behaviors for any Steps created from those blueprints. See more on Fields.

Upserting

Steps::Upsert runs the expected procedure to create or update a Step. It will handle things like:

• handling both create and update
• creating audit trails
• handling uploads
• updating parent workflows
• indexing searchable fields
• and more...