Status: Whether to set the user to Active or Inactive.

User Email: The email address of the user whose status should be set. You can build an email address here using Liquid.

Message: Text here will be added to the transaction's activity panel, as though one of the participants had made a comment. This field supports both Liquid and HTML.

Author Email: The attribution for the comment. If this is the email address of a known user, their name will be filled in. If it is not, then the address given here will be quoted as is, and shown with a strikethrough. You can use Liquid variables to retrieve or build an email address.

Message: Text here will be added to the transaction history. This field supports both Liquid and HTML.

Event Type: Select a type from the drop down menu. This type is used in certain reports.

Add a participant with a specific role to the transaction.

Emails: List of comma separated emails of users to add. This field supports Liquid expressions to get emails from fields in the transaction or to conditionally include an email. If you include the email address of a user that doesn't already exist, the user will be created.

You can specify the user's full name, as well, though you're not forced to. Doing so is useful in the case where a new user is being added, so that the user creation process has access to the full name. To do this, put the full name first, immediately followed by the email address in angle brackets.

Example:

[email protected],John Doe<[email protected]>,[email protected]

Role: Role of the added users.

Liquid Role (Overrides Role): You can put a Liquid expression here so that when adding multiple participants in a single action, they can have different roles.

Phase: Either ‘App Configured’ or ‘Current’. ‘App Configured’ means the user is added to the phase in which the user is configured in the App Builder Phases tab. ‘Current’ means the user will be added to the current phase.

Add participants with specific roles based on a decision table.

List Name: The list that holds the decision table. See General Administration for more information on decision tables. The table should return the role and the email of the participant being added per row.

Email: The user's email address. You can get it dynamically with a Liquid expression.

User Group Name: The group to add to. You can get the name with Liquid.

Client: Client ID retrieved from Adobe Sign website.

Client Secret: Client secret retrieved from Adobe Sign website.

Redirect Uri: URL you will be redirected to when retrieving the refresh token. The client will never see this URL.

Refresh Token: Value retrieved from making a POST request to Adobe Sign with Client ID, Client Secret, and Redirect Uri.

X Api User: The email associated with the Adobe Developer account in the following format: email:[email protected]

Adobe Sign Transaction Id Field: Field name to link Record with Adobe Sign document.

Document Field: Field that will store the document to be passed to Adobe Sign for signature.

File Name (Override document default name): File name that will override the uploaded document's default name.

Agreement Name: Name of the Adobe Sign Document.

Recipient Emails: Recipient emails for the Adobe Sign Document.

Cc Emails: CC emails for the Adobe Sign Document.

Last Error Success Field: Name of Field that will display error from Adobe Sign.

Last Error Desc Field: Name of Field that will display error message details from Adobe Sign.

Client: Client ID retrieved from Adobe Sign website.

Client Secret: Client secret retrieved from Adobe Sign website.

Redirect Uri: URL you will be redirected to when retrieving the refresh token. The client will never see this URL.

Refresh Token: Value retrieved from making a POST request to Adobe Sign with Client ID, Client Secret, and Redirect Uri.

X Api User: The email associated with the Adobe Developer account in the following format: email:[email protected]

Adobe Sign Transaction Id Field: Field name to link Record with Adobe Sign document.

Status Field: Name of Field to display Adobe Sign status.

Signed Document Field: Name of Field where signed document will be uploaded and stored.

Agreement Info Field: Name of Field to display Adobe Sign info.

Give an approval. If you are logged in as a user that is not an approver, it has no effect. You can also use the action for proxy approval.

Comment: Text here is automatically added to the activity panel, when this action runs. The field supports both HTML and Liquid. (Note however that bulk actions do not support Liquid; so if this action is triggered by a bulk action button, the Liquid will not render.)

Parametrized Comment: This box is used to add a comment to bulk action approvals. When it's checked, the user that applies an approval bulk action will see a popup dialog box for comment entry. The comment will be made in all transactions where the approval action happens.

Endorsement: This field is used when proxy approving. It expects the database ID of an approver role + status. Roles and statuses are kept in an array called "endorsements". As a rule, you'll provide Liquid that will loop over this array and find the one you want. For example, if you wanted to find an endorsement belonging to Approver 4 you might use:

{% for e in endorsements %}{% if e.name == 'Approver 4' %}{{e._id}}{% endif %}{%endfor%}

Note that the above assumes that Approver 4 has only one role in the transaction. If the Liquid might return more than one ID, you need to make sure that they are separated by commas. This is easily done simply by inserting a comma after the output:

...== 'Approver 4' %}{{e._id}},{% endif...

Custom Approval Method: When a proxy approval is done, App Builder puts a message in the transaction history, recording who did it and by what method. For example, "[email protected] proxy approved [email protected] by email." Put text in this field (or Liquid that evaluates to some text) and it will be used in the "by ... " part of the message.

Phase Name: The drop down menu has a list of the app's phases. Select one. When this action is applied to a transaction, its phase will be set to this.

This action sets the phase for transactions related to the current one.

Relation Property: The field's name that has the related transactions; type ManyToMany, HasMany, or BelongsTo. The drop down menu will give you the names of all eligible fields.

Phase: The name of the phase you want to change the related transactions to. This must be a phase that actually exists in them.

Apply this action to a transaction to close it.

This action is applied to transactions related to the current one; it sets them to Closed.

Related Atom Field: The name of the field that contains the related transactions. Its type can be ManyToMany, HasMany, or BelongsTo. The drop down menu will list the eligible fields.

This allows you to run multiple actions in a specified order, when certain circumstances are met.

Condition: Select a condition from the drop down menu. Conditions are created in the Conditions panel. This controls when the action will trigger.

Actions: Select an existing action from the drop down menu. It will be saved to the panel. You can keep adding actions. You can delete an individual action by clicking the X icon next to its name, or use the X icon at the right to clear the whole field. Actions will run in the order that you select them. You can change the order by clicking on an action's name and dragging it.

Use this action to take a document that is attached to one transaction, and make a copy of it in a transaction that is related. The copies are separate, so that if one is deleted, others are not affected.

Source Attachment Property: This drop down menu will give a list of the attachment fields in the app. Choose the one you want to copy from.

Related Atom Field: A drop down list of the app's relation fields. It indicates where the copy will go.

Related Atom Attachment Property: The name of the target app's field that will receive the copied document.

Document ID field: A Text or Textarea field (not an HTMLfield) which will contain the list of documents. Document ID's are a string of hexadecimal. Separate multiple ID"s with a comma.

Attach To: The Attachment field or DocumentFolder that will receive the copied documents. Attachment fields can only hold one document; if you copy several, it will end up with the first in the list and the rest will be discarded. 

Attach To: A document folder field or attachment field, to copy the attachment document into. If there is more than one attachment, a document folder will receive all of them; an attachment field will take the first one.

Add a list of related transactions based on a list dictionary definition.

Related Atom Field: The field to which the related transactions will be added.

List Name: The name of the list that defines the template for the related transactions. The list dictionary columns represent the fields to be set in the related transaction. Each value in the list will be processed by Liquid similar to a calculated field. You can also have a condition column which tests whether a specific row should be created. It should take the same format as Conditions described below. The condition column must be named _condition.

Copy Documents: Check this box to copy over any documents attached to the current transaction into the newly-created one. If the created atom is in a different app, you'll need to make sure that it has an attachment field or document panel with the same name, to receive the document.
Note: if the list has a column for the field or panel, the action will fill in field with the value from the list, and that will prevent the document copy from happening. So if you know you want to copy attached documents, omit the attachment field from the relevant list.

Important note: All atoms must have a name and a requester. When creating a related atom in the normal way, App Builder will copy these from the fields in the source atom. When using this action, it does not. So the fields

• name
• requester_email

must be set as calculated fields in the target app, or you must set them in your list. The attempt to create an atom with either of these fields not set will fail.

This action creates a token for a user that allows them to reset their password.

User Email: The user whose password needs resetting. You can build an email address here using Liquid.

Once the token is created, a filter "reset_password_url" then exists. When you filter the user's email address with this, it outputs a URL that directs to the reset password page.

So to make this work, you'll need to create a Conditional Compound Action that first runs this action, and then uses a Send Notification action to send it out. In the body of the Send Notification, you'll have something along these lines:

{% assign url = '[email protected]' | reset_password_url %}
{{ 'Reset my Password' | button_link: url }}

If you're using Liquid to build the email address for the Create Token action, use similar Liquid in the assign statement: it just needs to evaluate to the same email address.

Add new atoms (to the same app or a different one) based on existing atoms.

Source App: The app with the existing transactions.

Source Transaction Filter: You don't have to create atoms based on all transactions in the source app; select a filter here to get a subset. This is a required field; but if you want all transactions, you can create a filter that returns them all (with the very simple filter JSON of "[]").
Note: If you click on this drop down before you have selected a Source App, you'll see a list of every filter in every app. Select a Source App in order to reduce the list down to just the filters available in that app.

For filtering purposes, you may need to access properties of the atom which is the context in which the Create Transaction action is running. You can do this with the Liquid variable invoking_atom. So for example, if you want to find the atom's name, you can use {{invoking_atom.name}}. (As usual, fields other than the three defaults need a p_ prepended: so if the atom has a field called "invoice_number" and you want to use what's in it, that would be:
{{invoking_atom.p_invoice_number}}.)

Target App: The app in which the new transactions will be created.

Target Relation: WARNING: NORMALLY YOU WILL NOT WANT TO SET THIS VALUE. If you set the value of target relation, child atoms that are created by the action won't be related to the parent atom that calls the action, instead they will be related to the parent of the source atoms. IF YOU WANT THE NEW CHILD ATOMS TO BE RELATED BACK TO THE PARENT ATOM THAT FIRED THE ACTION YOU MUST SET THE r_id VALUE MANUALLY.. e.g. "r_[belongs_to_field]_id:{{atom.id}}" If you want the new atom to have a relation to its source atom, set the relation field here. Note that if you click on this drop down before you set the Target App, you will see all relation fields for all apps on the server. Once the Target App is set, this will filter down to just the fields in that app.

New Transaction Params: Use this to set values in the new atoms. Enter colon-separated pairs. The left-hand side of the pair is a field name in the target app. As usual, except for the default fields of "name", "requester_name", and "requester_email", the name must have "p_" before it. The right-hand side is a Liquid expression. If you want to reference fields in the source atom, use source_atom.[field_name].
E.g., if your source atom has an invoice ID, and you want to copy that to the target atom's invoice ID field, you would use:
p_invoice_id:{{source_atom.invoice_id}}
If you want to reference properties of the atom in which the action is running, you have the variable atom. Often you might want to set up a relationship between the newly created atom and the current atom. To do that, use the name of the relation field, with r_ in front and _id after, and set it to the atom ID of the current atom. So if the new atoms have a BelongsTo field called my_parent, enter this in the Params:
r_my_parent_id:{{atom.id}}

Important note: All atoms must have a name and a requester. When creating a related atom in the normal way, App Builder will copy these from the fields in the source atom. When using this action, it does not. So the fields

• name
• requester_email

must be set as calculated fields in the target app, or you must set them in the New Transaction Params. The attempt to create an atom with either of these fields not set will fail.
(App Builder will retrieve the requester_name based on the provided requester_email, so you don't need to set requester_name – indeed, if you do then what you set will be overwritten.)

From User Email: The email address of the person who is delegating their authority. You can get the address from a Liquid expression.

To User Email: The person who will receive the delegated authority. This likewise can be Liquid.

Destroys the document that is present in an attachment field.

Attachment: The attachment field's name.

Delete a transaction.

Deprecated.

Deprecated.

URL: The value of this property will change depening on whether or not you're configuring this Action during development or production. In both cases you'll need to edit the account number for this URL. For development: The default URL value in this property refers to a non-Production DocuSign server (e.g., demo.docusign.net). For Production: Use a Production DocuSign server for the URL (e.g., https://www.docusign.net/restapi/v2/accounts/4158891/envelopes). Note: The account number in the URL will also likely change again in production to the client's DocuSign Production account number, as opposed to the Developer account.

Headers: This defaults to "accept:json". Change this property's value so that the X-DocuSign-Authentication header references the appropriate Username, Password, and IntegratorKey.

Liquid Params: This property accepts parameter key:value pairs where the value may be Liquid. These params will be appended to the URL provided above.

Body JSON: The Body JSON property will identify the type of DocuSign enveloped to be created. The out-of-the-box DocuSign template App will contain some sample JSON, which you will likely need to customize. For more information about customizing the JSON see this tutorial.

Document Field: Name of the Field where the document to be signed is attached.

Document Key: Unique key used to identify your API integration. This key is required to authenticate your API calls with DocuSign.

Status Field: Name of the Field that DocuSign will used to save API responses.

Success Status Message: Optional pre-written success message to display upon DocuSign success.

Error Status Message: Optional pre-written error message to display upon DocuSign error.

New Phase: Name of Phase to change Record to when signed Document is returned to Onit.

Signed Document Name: Name of signed document. Suggested Liquid is as follows: 

{% capture name %}{% attachment_link_document %}{% endcapture %}{{ name | strip_html |remove:'.docx'|remove:'.doc' }}.pdf 

This Liquid will capture the name of the signed Document and append .pdf to the end.

Signed Document Field: Name of the Field where the signed document should be stored.

Signed On Paper Field: Name of a checkbox field. Check this checkbox when the document has been signed on paper instead of DocuSign.

Transaction Fields to Update: Fields to update when the signed document has been received. Should be in fieldname:value format.

Signed Document Status Field: Name of the Field to store status of the signed document. (e.g., Completed, Declined)

Declined Reason Field: Name of Field that will store the reason a DocuSign document was rejected instead of signed.

Last Docusign Post Message: Liquid that evaluates to the last POST message received from DocuSign. {{webhook_params.DocuSignEnvelopeInformation.EnvelopeStatus.EnvelopeID}}

Last Docusign Post Field: A TextArea field.

Configure a document to be sent to EchoSign for signatures.

EchoSign "Name": The name value that appears in the EchoSign email.

EchoSign "Message": The message that appears in the EchoSign email.

Receipient Emails: List of emails for the signers.

CC Emails: List of emails for anyone to be notified of this action.

API Key: EchoSign API key (from the EchoSign account).

Document Field: Select the field which the represents the document to be signed.

Document Key: Select the field that represents the document key.

This action searches for a related atom that fits criteria you set.

Related Property Name: A drop down menu with the available relation fields. The target app of the action will be the target app set for that field.

Relation Field Name: The action will look at the values of the possible related atoms to try to find the right one. Here, you tell it which field to look in. If this is a custom field, the name must be prepended with "p_". (E.g., if you want to look at a field named vendor_name, you'd need to put p_vendor_name.)

Relation Field Value: Here, you tell the action what to look for, as the value of the field set just above.

Params Liquid: The update instructions for the atom once found, or the values to set in the atom when it is created. This is similar to the Liquid section of an Update Transaction action. As there, you use colon-separated pairs, each one on a new line. You can use Liquid on either side of the pair. And as usual, names of custom fields must have "p_" prepended.

Operation: Use this drop down to control what the Action does if it can or can't find an existing atom.

• Insert: The Action will create a new atom if none is to be found, following the parameters it's given in Params Liquid. If it does find one, it will stop and do nothing else. Note that this does not necessarily mean that a new atom will be created: this will happen only if no atom already exists.
• Update: If the Action finds an atom, it will make changes to it, following the parameters. However, if it can't find one, it won't do anything.
• Upsert: a portmanteau of "Update" and "Insert", this means that the Action will update an existing atom if it can find one, and go ahead and create one if it can't.

Used to configure automatically generated documents.

Template Name / Condition: Enter the document template name or use a Liquid expression that evaluates to the name of the document template.

Auto Fix Template: Check this box.

Attachment Property: Name of the Field for the generated document to populate.

Saved File Name: Name of the generated document. Liquid may be used in this Field.

Populate Table with Related Transaction: Use this configuration to populate a Word table with related Records.

Word Bookmark Name: Name of table bookmark in Word.

Relation Field: HasMany Field name.

Relation Field Filter: Optional appropriate filter.

History Name: Type of history event. (Optional)

History Message: Message that will show in Record history. (Optional)

This action looks across a relation field (HasMany or ManyToMany) and pulls data from the related atoms into an Excel spreadsheet. For a full treatment, see Generating Spreadsheets. See also Generating a Spreadsheet on ScreenSteps.

Template Name: A Liquid expression that evaluates to the full name of your spreadsheet template, including suffix (e.g., .xlsx). Note that this is case sensitive: children.xlsx does not match Children.xlsx.

Attachment Property: The name of the Attachment field that the generated sheet should be saved into.

Saved File Name: The name you want your generated sheet to have. Here too you can use Liquid.

You'll need to add at least one range to Data to Export. Click the Add button.

Excel Named Range: The named range of cells in the spreadsheet template to look at.

Relation Field: The name of the field to loop over to get data.

Relation Field Filter: If you don't want to pull data from all related atoms, you can apply a (previously saved) filter to them.

History Name: The type of event this action shows as in the View History window.

History Message: The message shown in the View History window when this action occurs.

Used to check and return a document sent for signatures.

Document Key: Select the field that represents the document key.

Signed Document Field: Select the field that will store the returned document. The field type must be Attachment.

Signed Document Status: Select the field that will store the document's status. The field type must be Text.

Used to check and return a document sent for signatures.

API Key: EchoSign API Key from EchoSign account.

Document Key: Select the field that represents the document key.

Signed Document Field: Select the field to store the returned document.

Signed Document Status: Select the field to store the document status.

Used to check and return a document sent for signatures.

API Key: HelloSign API Key from HelloSign account.

Document Key: Select the field that represents the document key.

Signed Document Field: Select the field to store the returned document.

Signed Document Status: Select the field to store the document status.

Configure a document to be sent to HelloSign for signatures.

HelloSign "Name": The name value that appears in the HelloSign email.

HelloSign "Message": The message that appears in the HelloSign email.

Receipient Emails: List of emails for the signers.

CC Emails: List of emails for anyone to be notified of this action.

API Key: HelloSign API key (from the HelloSign account).

Document Field: Select the field which the represents the document to be signed.

Configure an action to send signature request using a template defined in your HelloSign account.

Signature Request "Subject": The subject value that appears in the HelloSign email.

Signature Request "Message": The message that appears in the HelloSign email.

Signer info: List of emails and names for the signers. 

<role_name>_email=<value-for-email>,<role_name>_name=<value-for-name>
[email protected],employer_name=Kate Cloud,[email protected],employee_name=KateEmployee

CC Emails: List of emails for anyone to be notified of this action.

HelloSign API Key: HelloSign API key (from the HelloSign account).

HelloSign Template ID: HelloSign Template ID.

Signature Request ID: Select the field that represents the document key.

Custom Fields: Fields from the application that corresponding to the custom fields defined in the HelloSign Template.

Run a Kettle job at a specified time in a transaction's workflow.

URL: The URL of the Kettle job.

Job ID: Field that stores the job ID.

Job Name: Field that stores the job name.

Job Status: Field that stores the job status.

Job Action: Run, Execute, or Get Status. Run will launch the job with the name specified in the Job Name field and will fill in the job ID and status. Execute will [TK]. Get Status will just update the status for the job with name and id matching the name and ID fields.

Initial Actions (fires exactly once): Action that will fire once before your loop executes.

Max Loops: Max number of iterations before the loop will be terminated. Note: The system limit is 999.

Loop Condition: A condition created on the Conditions panel. Once this condition evaluates to false the loop will break. (e.g., {% if iterator_value < value_to_check_against %} true {% else %} false {% endif %})

Looped Actions: Actions to run for each iteration of the loop.

Action Type: Select one of the three available action types, and in the dialogue box for the Action it will be present as the initial value. 

Parametrized Action Type: Must be checked. 

Old User: Initial value of user to replace, or remove. 

Parametrized Old User: Must be checked. 

New User: Initial value of user to add when the action type is Add or Replace. 

Parametrized New User: Must be checked. 

Roles: Initial value of role to assign new user. 

Parametrized Roles: Must be checked. 

These four checkboxes must be checked. Right now you can't even save your action if any is not checked. (You might well ask, why bother with the checkboxes at all? To allow for future development.)

History Name: The effects of this action on participants are logged in the atom history, the same as when participant addition or deletion happens in other ways. There is also a specific entry that shows this action was triggered. The entry here is what will be logged under Event.

History Message: The message that will be logged under What.

A removal action should have Old User populated and New User blank, an addition action the reverse.

This action allows the creation of a report (customizable using Liquid) with Records from up to two different Apps.

Test Mode: When this box is checked, the report will go only to the address given in the Test Email field. Useful for testing without bothering the end users.

Test Email: As above.

Subject: The report email's subject line. You can use Liquid here.

Body1: The report's body. This field supports both Liquid and HTML.

Transaction Filter 1: Filter applied to Records in Body1. This property must have a filter chosen for Action to fire.

Body2: The report's optional second body. This Field supports both Liquid and HTML.

Transaction Filter 2: Filter applied to Records in Body2. This property must have a filter chosen for Action to fire.

User List: List of users the Multi Report will run the Raw Transaction Filter(s) on. This list is different from the Raw User Filter that will determine who will receive the report.

User List Body: HTML and Liquid body of the email. This body will be populated with the Records returned by the Raw Transaction Filter in the Filter for User List Body.

Filter For User List Body: Raw Transaction Filter to be applied to Records in User List body. This property must have a filter chosen for Action to fire.

Params Liquid:

PSB Comment Create is used to add comments to the invoice and BAR. This is part of the configuration is needed to automatically capture comments made in App Builder (for example, when rejecting an invoice or a timekeeper rate) and copy them into BillingPoint.

Commentable Type: The type of object which will receive the comment. For example: 

• billing_authorization_requests for BAR
• Invoice for invoices
• ClientTimekeeperRate for TK Rates

Commentable: Liquid that evaluates to the ID of the item that will receive the comment. For example, {{atom.psb_invoice_id}}.

Comment: The comment that will be placed. Generally this will use Liquid, to capture the App Builder comment.

Email:

Parametrized Email:

Configuration for App Builder - BillingPoint integration.

Psb Object: The type of object that will be created. For example, client_project or payment.

Params Liquid:

Allow Upsert:

Upsert Key:

Configuration for App Builder - BillingPoint integration.

Psb Object: The type of object to be destroyed. Options are "Client Project", "Billing Authorization Request", "Invoice", and "Client Timekeeper Rate".

Configuration for App Builder - BillingPoint integration.

Relate Property:

Psb Key Field:

Psb Object Type:

Params Liquid:

Use this to make an object in BillingPoint enter a new state. For example, to move an invoice from "Pending Approval" to "Approved".

State Event:

Step:

Psb Object Id Field:

Psb Object Type:

Params Liquid:

Update calculated fields on a set of atoms in an application.

Raw Transaction Filter: Select a filter to identify which atoms need to be recalculated.

Target App: Select which app needs to be recalculated.

Give a rejection. If you are logged in as a user that is not an approver, it has no effect.

Related Transaction Id: Atom ID of the Record to be related. You can use a Liquid expression to set this value.

Related Property Name: A dropdown list of relational Fields on the current App. Choose the Field that relates to the target App.

User Email: A corporation user's email address. When this action fires, all work delegations for the user will be ended.

This action removes one or more participants from the transaction, and does not replace them.

Roles to remove: Using the drop down, you can select one or more non-Requester roles. When this action fires, it will remove the participants who are present with these roles.

Remove everyone except requester: When this box is checked, the action will delete everybody, leaving only the Requester. (A transaction must always have a Requester.) Note that if roles are present in the 'Roles to remove' field, and this box is checked also, it is the checkbox that will take priority.

Skip Participant Deleted Business Rule: Some apps may have business rules that fire actions (such as sending a notification or adding a comment) when a participant is deleted from a transaction. If this box is checked, however, any such business rules will not be triggered. Note that the action will always make a record in the transaction's history, whether the box is checked or not.

Email: The user's email address. You can also enter a Liquid expression that returns an email address.

UserGroup name: The name of the UserGroup (which also can be retrieved using Liquid).

Changes the state of the current transaction from Closed back to Open.

This action allows you to choose a participant by role, and replace them on the transaction with someone new.

Role: The role that will be replaced.

Phase: Either App Configured or Current. If App Configured, then the new participant will be put into the same phase as the old. If Current, the new participant will be put into the transaction's current phase, and so will immediately be active.

Participant Name: A Liquid expression that returns the new participant's name.

Participant Email: A Liquid expression that returns the new participant's email address.

Participants List Name: Name of list that contains participants to be replaced.

Field in list that matches with App field: Name of column in list that matches name of Field in App.

Roles: Roles to replace. You can select multiple roles.

User for logging: Email of user who will show in the History logs when participants are replaced. 

Example: Multiple participants need to be replaced on a handful of Records. The App Builder Developer creates a list of new users to replace the existing users. Then the App Builder Developer configures a Replace Participants Action and assigns the list of new users to the Action. The App Builder Developer then executes the Action to replace the participants.

URL: URL of the endpoint you want to call.

Call: GET, POST, PUT, or DELETE.

Oauth Url:

Oauth Username:

Oauth Password:

Oauth Params:

Headers: By default this will be 'accept:json'. This will only change if there are specific header requirements for your API endpoint.

Liquid Params: This property accepts key:value pairs where the value may be Liquid.

Body JSON: If your API endpoint requires a body enter it in the Body JSON.

Attachment Field: Attachment Field for any attachments to be included in the request.

Status Field: Field name that will hold the API response.

Success Status Message: Default message that will show in the status Field when the API returns success.

Error Status Message: Default message that will show in the status Field when the API returns an error.

This is a specialized action intended for use with the execute_reaction_url Liquid filter. (See Liquid Markup Examples.) Do not use it in other situations.

Message: The message to be displayed. As usual, supports Liquid and HTML.

This action allows you to choose other atoms: either all atoms within an app, or all atoms that are related to your current one. (In both cases, you can filter down to a subset.)

Run on: Choose App to run on all atoms that are part of an app; choose Relationship to run on related atoms.

Relationship: The relation field to look at, when Relationship is selected above.

App: The app to target, when App is selected above.

Action: The action to run.

Filter: If you don't want to run the action on every related atom, use a filter to reduce the set of atoms down to the ones you do want. If your filter uses Liquid, the context is the atom that invokes the RAT action.

Run in Background: By default, when this action runs, it prevents you from doing any other actions until it's finished. If you anticipate a run that will take a long time, you can check this box. If you do that, the action happens in the background while you can do other things. The downside is that you don't see the effects until you refresh.

Used to create a meeting invitation that can be imported into a Calendar App.

Summary: The meeting title.

Description: A longer meeting description.

Start Date: The meeting's start date. This field and the next few support Liquid, so you can pull data from another field or use now. Format is YYYYMMDD.

Start Time: Start time, formatted HHMMSS; 24-hour time for HH.

End Date: The meeting's end date. This field and the next few support Liquid, so you can pull data from another field or use now. Format is YYYYMMDD.

End Time: End time, formatted HHMMSS; 24-hour time for HH.

Time Zone: The time zone for the above two times, in Olson database format.

Location: The location for the meeting.

Organizer: An email address.

Attendees: Email addresses of the people who will receive the invitations.

Set Alarm: Check this box if you want attendees to get a reminder about the meeting beforehand.

Alarm Unit: Minutes, hours, days, or weeks.

Alarm Value: How long before the meeting you want the alarm to go off, in the given unit.

Send custom email notifications about a comment added to a transaction. Email notifications will be delivered to participants on the Record.

Test Mode: When this is checked, the notification will go to the address given in the Test Email field. Useful for testing out a new configuration without bothering the actual end users.

Test Email: As above.

From Name: Name that will show in the header of the notification email.

From Address: Email address that will show in the header of the notification email.

Reply-To Name: Name that will show in the header as who gets responses.

Reply-To Email: Email address that responses will go to.

Layout: Select which email layout to use for the notification.

• Standard - displays the email with borders and a restricted width.
• Standard/No Header and Footer - uses a layout like Standard, except without the header displaying the app name or the footer displaying an Onit copyright notice.
• Plain - displays the email without any restrictions or borders.

Subject: The email notification's subject. You can use Liquid here.

Body: The email notification's body text. You can use Liquid here. You have access to the comments variable in Liquid.

Transaction Filter: The filter to limit the set of atoms.

Role: The set of atoms is further limited to atoms on which the user has this role.

This action is part of App Builder - BillingPoint integration. It allows the sending of an email notification when a comment is entered in BillingPoint. (This can happen either from the BillingPoint side, by a BillingPoint user, or from the App Builder side via the BillingPoint view in an app panel. The action is not able to tell which is the case.)

Test Mode: When this is checked, the notification will go to the address given in the Test Email field. Useful for testing out a new configuration without bothering the actual end users.

Test Email: As above.

Roles: You can use this drop down to choose roles that exist in the app. (Including roles that are disabled.) The notifications will be sent to these participants. There's also an option to send to everyone on the transaction, and to everyone except the transaction's requester.

Restrict Roles to phase: When this is checked, the notifications will be sent only to participants who are active in the current phase.

Emails: If you want the notifications to go to people who aren't necessarily participants, you can put their email addresses here.

Email Fields: Notifications can also go to people whose email addresses are recorded within the transaction itself. (For example, the law firm billing admin.) Select the field or fields that contain the addresses using the drop down menu.

Layout: There are three possible layouts:

• Standard - displays the email with borders and a restricted width.
• Standard/No Header and Footer - uses a layout like Standard, except without the header displaying the app name, and the footer displaying an Onit copyright notice.
• Plain - displays the email without any restrictions or borders.

Subject: The email notification's subject. You can use Liquid here.

Body: The email notification's body text. You can use Liquid here. You have access to the comments variable in Liquid.

History Name: An identifier for logging.

History Message: The message put in the log.

Send custom notifications with specific language and recipients.

Test Mode: Allows you to set the action in test mode.

Test Email: Email to send the notification to when the action is in Test Mode.

From Name: Name that will show in the header of the notification email.

From Address: Email address that will show in the header of the notification email.

Reply-To Name: Name that will show in the header as who gets responses.

Reply-To Email: Email address that responses will go to.

Roles: Select one or more roles from the application that will determine who receives the notification.

Restrict Roles to Phase: Restricts the notification to the roles specified who are also on the current phase.

Emails: One or more email addresses for which will receive the notification.

Email Fields: Select an email field from the application to read the email address from each transaction.

Layout: Select which email layout to use for the notification.

• Standard - displays the email with borders and a restricted width.
• Plain - displays the email without any restrictions or borders.

Subject: The subject of the email notification. Liquid can be used here.

Body: The body of the email notification. Liquid can be used here.

History Name: The name (or type) of history element to log.

History Message: The message to log in the history.

Used to configure a notification for a report on a set of transactions. Unlike other actions, this action operates on a user as opposed to a transaction. The user will be the recipient of the email.

Test Mode: Allows you to set the action in test mode.

Test Email: Email to send the notification to when the action is in Test Mode.

Subject: The subject of the email notification. Liquid can be used here.

Body: The body of the email notification. Liquid can be used here. The set of transactions is represented in {{atoms}}. See Appendix for example of report Liquid.

Transaction Filter: The filter to limit the set of atoms.

Role: The set of atoms is further limited to atoms on which the user has this role.

Email of Delegator: Email of user who is assigning out of office delegate.

Emails of Delegate: Email(s) of user(s) who will be assigned out of office delegates.

The Action is responsible for creating, updating or upserting Records from a flat file. The Action can also be configured to delete Records when their corresponding data row is missing from the imported file. See related tutorial here.

Note: This Action is only compatible with UTF-8 encoded files.

File Operation: Determines the Action's overall scope. Options are Insert, Update, or Upsert.

Delete Missing Rows: If a row exists in the App but does not exist in the flat file, the Record will be deleted.

Target App: App containing the Records to create/update/delete.

Change Phase on completion: Phase to change the Record to once data ingestion is completed.

CSV to import: Name of the flat file Attachment Field.

Column separator: The delimiter value used in the flat file (e.g., a comma (,), or a pipe (|).) The default is set to a comma.

Quote separator: The escape character for quotes in the flat file. The default is a double quote (").

Date Format: Liquid date format (e.g., %Y/%m/%d)

Template File: Template sample flat file.

Field Mappings: 

Key Field: Indicates which Field will be used as a key. Only one key is recommended.

Calculated: If the Source property contains a Liquid expression check this box.

Source: Mapping of data from the flat file into the specified App (e.g., {{row.column_name }} ). Can contain Liquid expressions.

Property: The App Field where the data will be ingested to.

Used to change what atoms are related in a particular panel, based on the contents of a MultiSelect field.

MultiSelect Field that serves as data source: A drop down menu with all the app's MultiSelect fields.

Relationship that will get updated: A drop down menu with all the app's relationship properties.

Error Message: Error message to be displayed to end users.

This Action is used to update a Record with data from a REST Store.

Server Url: URL of endpoint to make a GET request to

Store Root: Optional root URL of REST store

Params Liquid: Optional Liquid params to specify data.

This Action is used to keep Multi Currency Fields updated based on Spot Rates. If you are working in an ELM environment this Action uses the Spot Rate Provider configured in the Corporation Settings. 

If you are not working in an ELM environment you will need to provide a Spot Rate Provider List with the following Fields:

• currency_code  (string - currency ISO code)
• effective_spot_rate (numeric)
• effective_date (date)

Field Mappings: 

Source: Source of the specific list or Field containing spot rates

Target: The Multi Currency Field to be updated

Example: A Multi Current Field is updated based on a list of current Spot Rates hosted in the App.

This action reads an attached spreadsheet, and then writes data across a HasMany-BelongsTo relationship into child atoms. For more on how to configure the spreadsheet template and use this action, see [1].

Perform In Background: Check this box to make the update actions happen as background processes.

Field Label Named Range: The section of the spreadsheet (a named range of cells) that contains the names controlling which fields will be updated.

Field Data Named Range: The section of the spreadsheet (a named range of cells) containing the data to be copied.

Attachment Property: The name of the attachment field where the spreadsheet will be found.

Relation Property: The name of the HasMany relation field connecting the current atom to the child atoms.
Note: This action works only across HasMany, not ManyToMany.

Relation Property: The field (a ManyToMany, HasMany, or BelongsTo) that relates the current transaction to the ones you want to update.

Params Liquid: Key-value pairs with a colon. The first half is the field to update, in the related transaction; you need to put "p_" in the front for all custom fields (i.e., all except the default three of name, requester_name, and requester_email). The second half is the new value to put in. This second half supports Liquid, with the context of the current transaction. To update multiple fields, put them on separate lines separated by a carriage return.

Some examples:

name: some value
p_another_field: {{name}}
p_third_field:{% if foo== "cat" %}Hello Foo{%else%}Hello Bar{%endif%}

This action lets you update the tags on an atom by triggering a List Lookup UI Action. Note that it has to be "Update Tags Using List Lookup"; it won't work with "Update Tags".
Note: Any field updates in the UI Action will not happen. If you want to change field values, use an Update Transaction action.

UI Action: The name of the UI Action to fire.

Update the current transaction.

Params Liquid - preface custom fields with "p_". To update multiple fields use a carriage return after each field.

Example:

name: some value
p_another_field: {{name}}
p_third_field:{% if foo== "cat" %}Hello Foo{%else%}Hello Bar{%endif%}

Shared Liquid: You can use the "Shared Liquid" property to assign variable values that can then be used multiple times in the Field Update sections. 

Field Updates: Click Add for each field you want to change. Important note: You can use Params Liquid for your updates, or you can use the Field Updates sections. But not both. If you have any Field Updates, Params Liquid must be blank; and if you want to use Params Liquid then there must be no Field Update sections. (You can remove them with the Remove button.)

Field: Click here to get a drop down with the app's fields. Select the one you want to update.

Liquid: A Liquid expression that evaluates to what you want to put in the field. (Note that hardcoded strings also count as Liquid for this purpose.) Note that here you can use any special character freely, unlike in "Params Liquid" where colon (:) and comma (,) have special meanings that can't be escaped.

If you want to update a Multiselect field, give it a comma-separated list.

This Action should be used to update a Record with values from a pre-created table.

List Name: Name of the list to pull updated values from.

Order Field: Mapping to a key column in the list. 

Example: A pre-formatted list is exported from Onit of all the Budget Records containing Record details. The list is updated independently of Onit and an Update Transaction using Table Action is used to update the Records in Onit with the new data.

This Action is used to update a Record in object with data from an object in BillingPoint.

Step: Phase to change Onit Record to.

Psb Object Id Field: Field name in BillingPoint of ID for PSB object.

Psb Object Type: Psb object type, for example: "Client Project", "Billing Authorization Request", "Invoice", and "Client Timekeeper Rate"

Params Liquid: Data to be transferred from BillingPoint to the Onit Record, in the format { {p_onit_field : billingPoint_data }}

This action copies data from one atom into another. It searches for a target atom in some app. If it finds one, it copies the contents of fields you specify into the target, thus updating it. If it does not find one, it will insert a new atom into the app. (Upsert == update / insert.)

Target App: A drop down menu listing all apps available on the server. Choose the app you want the action to look at.

Filter Json: A JSON string with which to filter the atoms in the target app.
(Example: [{"type":"string","value":"\"{{name}}\"","field":"name"}] will search for an atom with the same name as the current atom.)
If the filter returns one atom, then this action will update that atom. If the filter returns more than one, then this action will update the first it finds. If the filter returns no atoms, then this action will create one.

New Phase: The target atom will be set to the phase given here. Since this is a required field, the target app set above must be one that has phases.

Params Liquid: Items here will be written directly into the target atom. Enter colon-separated pairs, one per line.
On the left side of the colon, put the name of a field in your new atom, with p_ immediately before.
(Example: if you will have a field called state_or_province, this becomes p_state_or_province.)
Exception: all atoms have the three fields name, requester_name, requester_email. For these three fields only, do not put p_ in front.
On the right side of the colon, put the data which will go into the field. This right side can use Liquid, with the current atom as the context.

Fields to be copied over: Here is where you specify what data is copied. Enter colon-separated pairs, one per line. Each half of the pair is a field name. On the left side of the colon, put a field name from the target atom; on the right, put one from the source atom. The action copies the data from the source field into the target field.

Use Fields to be copied over to copy fields directly. Use Params Liquid when you need to set calculated/derived values using Liquid.