Domains› Core Concepts› Workflows› Launch Workflows›

Launch From Entity Triggers

Have you ever thought: "Gee, I wish I could do something every time someone saves a person in the database." Well, with Rock you can! Entity triggers can be configured under Admin Tools > General Settings > Workflow Triggers.

  1. Trigger Type - You must select when the trigger will be fired. See notes below on the difference between pre and post events.
  2. Active - Determines if the workflow trigger is currently active. This is helpful if you want to temporarily suspend the trigger but don't want to delete it.
  3. Entity Type - Select the entity type you'd like to add the trigger to (e.g., Person, Group, etc.)
  4. Entity Type Qualifier Column / Value (Optional) - There are times when you will only want to run your trigger in certain situations. For instance, you may want to run a post-save trigger when groups of group type Serving Team are saved. In this case you would set the Qualifier Column to GroupTypeId and the Qualifier Value to 23 (the GroupTypeId for Serving Teams). These settings allow you to simplify your workflows for specific use cases.
  5. Workflow Type - Select the workflow type you want to launch. Be sure that this workflow saves the passed entity to an attribute so that it has access to the value being saved or deleted.
  6. Workflow Name - This setting provides a workflow name for the workflows that are created.

Caution

Saving While Saving
Be careful not to set up a triggered workflow that updates the entity that is actively being saved (for example, a pre-save or immediate-post-save trigger on a person that fires a workflow to update a property on that person). This can cause a loop that creates an out-of-memory condition which will make your server administrator pretty upset.
There are other related combinations that are also unsupported. Just because you can doesn't mean you should.

Pre vs. Post Trigger Events

You might be wondering what the difference is between a pre and post event trigger. There is a difference and it's pretty important that you select the right type.

Pre triggers launch the workflow before the save or delete occurs. The benefit of a pre trigger is that you can keep the save from occurring through the logic of your workflow. If your workflow returns with an error message, the save or delete will be aborted. Except in a few places, there is no means for these error messages to bubble up for someone to see, so keep that in mind when using pre triggers.

One downfall of pre triggers is that if they are initiated by someone working in Rock, that person must wait for the workflow to launch and complete before the save is completed. Because of this, you'll want to be sure that your workflows are simple and quick.

Post triggers, on the other hand, can’t keep a save or delete from occurring. By the time they launch, the save or delete has already been done. These triggers are launched but Rock does not wait to hear back from them before moving on. This keeps workflow performance quick.

Note

You Can Have More Than One
You can have more than one trigger for each entity type. This saves you from having to lodge all your logic in one workflow.

Tip

Use Post Triggers Whenever Possible
Because of their speed, try to use post triggers whenever possible.

Warning

Saved or Not Yet Saved
Even with an immediate-post-save trigger, if you try to fetch the triggered entity from the database in your workflow, there is a possibility that its data has not yet been written to the database. If it's critical that you know the exact values of the entity at the moment the workflow runs, you should capture the entity property in question with the Attribute Set From Entity action using {{ Entity.PROPERTYNAME }} or capture the whole object into a text attribute using {{ Entity | ToJSON }}. You can then safely refer to the correct value in subsequent actions.    

Save the Entity First

When using the Attribute Set From Entity action, you may be tempted to try to do more than it was designed to do. For example, if the entity you are working with is a Group Member, you might try to get the group's name using {{ Entity.Group.Name }}. Except the ".Group" property is not guaranteed to be there -- only the .GroupId will be there. In fact, even the {{ Entity }} will be gone after the initial activity.

Therefore, we recommend you always collect your Entity properties in your first few actions, before doing anything else. And second, if you need other related items, you should load them explicitly. So, to get that group name you can use {{ Entity.GroupId | GroupById | Property: 'Name' }}

Launch From Person Profile Launch From a Grid