Actions are executed after an event is triggered and all conditions (if any) are met.
Workflows can be made up of multiple actions, which are in turn, executed sequentially.
This action will let you add new App Records that will eventually be created when your specified event is triggered.
When selecting this action, you need to choose a specific App. This is where the new record will be created.
Once you select an App, you can set the Field values for the new record.
When setting Field values, you can choose between two options:
Note: To copy a Field value, a Field of the same type must exist in the record that triggered the workflow.
If there is an existing relationship between the App that triggered the Workflow and the App where you are creating the new Record, you can link the two Records together.
For example, when a new project is created, you can create a set of Tasks and link them to that particular Project.
This action will let you update the Record that initially triggered the Workflow.
You can use this action to automate manual processes, enforce data entry rules and improve data integrity.
For example, if you are using the Kanban View to drag & drop Projects between different statuses, this action can help you automatically update specific Field values when the Project Status is changed.
In the following example, when the Project Status is changed, we're automatically adding Ella Smith to the Responsible team members and setting the Project priority to High.
This option lets you send a custom notification to multiple members of your team. You can choose to notify the:
You can use @FieldName to write down Field values in your notification message.
This option lets you send an email to:
The From address must belong to one of the Users in your Fusioo account.
You can use @FieldName to write down Field values in your email message.
You can attach documents from File fields available in the record that triggered the workflow or any related records.
There are some restrictions in place to satisfy rules set by email providers.
If any of those restrictions isn't met, the email is still sent. However, the respective attachment is not included.
This option lets you use related records from connected Apps to send emails.
For example, you might have an App Relationship between your Tasks and Contacts App.
This means that each task can be related to a contact or multiple contacts. When you select Email related records, each contact will receive an email when a workflow is triggered on a specific task.
You can use @FieldName to write down Field values from the connected App in your email message. This way each email message will be specific to the person receiving it.
Webhooks are a simple way with which Fusioo can "speak" to other applications and notify them automatically when something new happens.
This is done by sending record information in the form of a JSON message, to a URL of your choice.
The JSON message formatting can be changed to satisfy the format required by the application receiving the data.
For example, to send a message in a Slack channel, you can change the previous JSON message to:
Before sending a webhook event, the JSON payload is validated. If the JSON is invalid, the webhook is not sent.
A webhook event is considered successful when the response status code is 200 (OK).
A webhook event will timeout after 60 seconds if no response is received.
The request is retried for 2 more times. If there is no response after 3 requests, the webhook event will be marked as failed.
The workflow activity log will display the reasons why the webhook event failed.
If the webhook contains invalid JSON, the request is not retried.
A "fus-signature" field is included in the request header, this field will contain a SHA256 HMAC signature. For example:
This signature is added to make it easy for you to check that the request originated from Fusioo and that the payload content wasn't manipulated.
The signature is generated for each request, by hashing the payload using a secret token.
This token is unique for your account (all users in your account will see the same secret token) and is displayed under each webhook action.
To verify that the content was not manipulated, you need to hash the request body with the secret token displayed in the webhook action. The result should match the signature contained in 'fus-signature'.
This option lets you make dynamic changes to the form, based on a specific set of conditions, while the User is manually entering data.
The conditions are checked and triggered both when the form is initially loaded and when a User manually makes changes.
Some use cases include:
Looking at the example below, the Project Closeout Section (and all Fields in that section) are displayed only when the status of the Project is set to Complete.
Apart from being displayed, some Fields within that section are also marked as required.
Type above and the results will be displayed here.