In this article:
- What Happens When You Sync Actionstep with Builder
- About Component Names
- About Catalog Models
- About Object Models
- About Individual Variables
- Additional Components
- Passing Client and Matter Data Between Actionstep and Builder
Before you begin:
- Familiarize yourself with Builder terminology.
- Familiarize yourself with the concept of object models and object variables.
When using Builder and Actionstep together, merge fields from Actionstep can be used as variables in your Builder template.
When you first set up Actionstep Builder and sync your data with Builder, the merge fields and participant/matter custom data fields you have in your Actionstep system are 1) copied into Builder and 2) repurposed as Builder components (i.e., catalogs, object models, and object variables). This creates a relationship between your participant and matter data and the components needed to generate documents in Builder.
This article attempts to explain how to best work with Actionstep-based components in Builder.
What Happens When You Sync Actionstep with Builder
When you first sync Actionstep with Builder, a few things happen:
1) Actionstep copies your matter types to Builder so that you can create catalogs and associate them with those matter types. (See Creating a Builder Catalog Model and Associating It with a Matter Type to learn more.)
2) Actionstep copies several system-level elements to Builder and creates object models from them. This includes:
- as:system: This covers system data, like your orgkey and the current date.
- as:action: This object model is used to display matter-related data, like the matter name and ID. It is used to create a Matter object variable in each catalog/matter type.
- as:action_participant: This object model includes all the participant variables, like name, address, birth date, etc. It is used to create custom participant-type object variables, like pt_Client, pt_Attorney, etc. You can identify custom participant object variables by their name: pt_[ParticipantTypeName]).
3) Two other system-level object models are created:
- as:pt_Client_custom: This object model represents the custom data fields for the Client participant type.
- as:pt_special_options: This object represents participant type merge field options.
4) Finally, Actionstep copies data collections for your specific matter types to Actionstep. You can identify them by their name: as:dc_[DataCollectionName].
About Component Names
This was covered briefly in the previous section, but Actionstep components that are used in Builder are named using special prefixes and suffixes. For example, all catalogs and object models use as: followed by what type of object it is—whether it's participant type data (pt_), matter type (mt_) data, or a data collection (dc_). If it's a custom data field, the suffix _custom is appended to the end of the component name.
The following table includes examples of these different components:
This is a catalog model (as indicated by the icon) that maps to the Conveyancing matter type in Actionstep. | |
This is a system-level object model that lists all of the data associated with participant types (like names, addresses, birth dates., etc.). Builder includes other system-level object models like as:action and as:system. | |
This is a catalog/matter type-specific object variable that is based on the as:action_participant object model. It lets you gather data for a specific participant type (like Seller). | |
This is an object model that maps to the Employment Details data collection in Actionstep. This data collection was set up as "Matter Data" for a Conveyancing matter type. | |
This is an object variable that maps to the PropertyDetails object model. | |
This is an object model that maps to a custom Participant Type (Lawyer) and its custom data fields in Actionstep. |
To learn more about Actionstep data types, see these articles:
- Participant Types Overview
- Participant Custom Data Overview
- Matter Types Overview
- Matter Custom Data Overview
About Catalog Models
Catalog models represent matter types in Actionstep. At the highest level, a catalog model contains all of the data (templates, objects, and variables) associated with a specific Actionstep matter type.
You can view catalog models in the following locations in Builder:
- Click the catalog model name in the global navigation bar to test-assemble any apps/templates associated with it.
- Click Catalog in the global navigation bar to set up or edit the properties of a specific catalog.
- Click Designer in the global navigation bar and view your catalogs in the Elements list. Catalogs are listed first.
You can identify a catalog model by its icon and name:
About Object Models
Builder supports the concept of object models and object variables. An object model contains a generalized set of variables that relate to its main purpose—gathering information about a participant or matter type. Once created, an object model can be used to “seed” object variables, which allow you to create catalog-specific collections of data. For example, an object model for generalized participant type data could be used to create object variables for specific participant types: a client, an attorney, a defendant, expert witness, and so forth.
An object model organizes generic variables like Name, Address, DOB, etc. into a single grouping. Based on these object models, you can then create party-specific object variables. This approach lets you create the variables once and then pull them into unique variable groups. This simple example shows you how:
You can view object models in the Elements list on the Designer tab in Builder. Select the object model to then view which variables are included in it. (This list appears on the Variables tab in the Details section.)
- Matter-specific variables can be found in the as:action object model.
- Participant type variables can be found in the as:action_participant object model.
- Data collection variables can be found in their respective data collection object models.
You can identify an object model by its icon and name:
About Individual Variables
Individual variables represent specific merge fields in Actionstep. Variables are the core components that are used in the template. Variables can either be standalone or part of an object variable. (To view the variables associated with an object variable, click the expand icon next to the object variable's name in the variables list.)
If the variable you need isn't available, you can create your own; however, if you want the data used to answer it during the interview to be saved to Actionstep, you'll need to first create custom data fields in Actionstep and then copy them to Builder. See Understanding Custom Data Field Types for more information.
Identification: You can identify a variable by its icon and name (it doesn't include any prefixes):
To view variables, click the Designer tab in Builder and then view the list of variables on the right side of the page. You may need to expand an object variable to view its individual variables.
Additional Components
Builder also includes two other default object models:
- as:action: Contains standard action/matter properties, i.e., Action_ID, Action_Name, and Action_Type. This object model is used to create an object variable named Matter for each catalog. You can use it to merge matter-related details, like matter name and matter ID.
- as:system: Contains organization-wide system settings, i.e., system_OrgKey and system-date. This object model is used to create an object variable named System for each catalog. You can use it to merge system-related details like the current date or your orgkey name.
Passing Client and Matter Data Between Actionstep and Builder
When assembling a document that has been automated using Actionstep-based variables, data will be pulled from participant type data or the matter and used in the document. At this time, however, data cannot be saved back to Actionstep outside of the assembled document.
Related Articles:
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article