The Activate Actions activity is like a clear history button for the current activity. When this action is run, all actions for the current activity are set back to Uncomplete. So next time this activity is processed, all actions will be run again. The current processing will continue however, so further actions will execute and possibly be completed. Normal use of this action would be to place it at the end of your activity.

Additional Details

This action will launch (aka activate) a new activity of the type that you choose. This action is used heavily to control the branching logic of the workflow. The use of action filters is very powerful with this action.

This action activates a specific activity in a specific instance of another workflow. This is really useful for terminating a workflow you've activated using the Activate Workflow action.

This action activates a new activity on all workflows that the activity belongs to when a given attribute matches a specific value. This is useful to activate a cleanup activity in a workflow where you don't know the workflow id but you do know about the value of a specific attribute in the workflow you'd like to complete.

This action launches a new workflow passing in any attribute values from your existing workflow. This action allows you to break up workflows into modular chunks making them easier to maintain, reuse, and build.

Activities can be assigned to a person or group to help distinguish who is responsible for ensuring that the activity is completed if there are manual steps to complete. This action will set the assignee of the current activity to the value of a workflow attribute.

These three actions do very similar things, so we'll group them together. Like the previous action, they set the assignee of an activity based on a provided person, group or security role. It’s best to avoid assigning actions to a specific person because you'll need to maintain this assignment as individuals transition into new roles.

This action is pretty obvious. It marks the current activity as complete. The activity will not execute any more actions.

This action will create and save an assessment request for each of the assessments provided, for the given person according to the attribute selected. You can also optionally provide a Due Date, and an attribute to define the person who is making the request.

This action will create a text file using a Lava template, then assign the resulting file to a workflow attribute. This action is useful when you need to dynamically create a text file using Lava, and then use that file in another workflow action.

When some workflows are started, they are passed an entity in the process. As an example, take workflows that are launched from the Actions list on the Person Profile screen. When these workflows are launched, they are passed an entity; in this case the profile person. This workflow action can assign the passed entity to an attribute, using a Lava template (via {{Entity}}), so that it can be used by subsequent activities and actions. Likewise, when a workflow is launched from a trigger the saved/updated object is passed as the entity to workflow.

When working with this action be sure to read the help text as it will guide you through many of the options.

This action will assign a selected person to a workflow attribute. This action is useful when you need to select a specific person to enter into an attribute.

This action sets the selected attribute to the current person. It's only valid if it's being run by a person through their interaction with a Rock page; most often using the User Entry Form action. In these cases this action is very helpful in storing the name of the person who completed the form.

This action sets the selected attribute to a group leader. This action is useful when you need to select a group leader in a specific group. If a group has multiple leaders (really a role with IsLeader property), the first one will be selected.

The Initiator field is a part of every workflow. It defines who started or launched each workflow. While each workflow has an initiator, the initiator field can't be used by most actions until it's assigned to an attribute. That's what this action is all about.

Sends a request for a background check to the selected background check provider. The person to run the check on must be stored in a workflow attribute with a key of Person.

This action will create a new benevolence request with options that allow you to complete many of the optional fields. The initial add does not allow you to set custom attributes or add documents, but there are actions you can use to complete those function once the request has been saved. The action will return the benevolence request making it easy to complete those follow-up steps.
Additional Details

Added the Benevolence Type required setting.v13.6

Adds a document to the provided benevolence request.
Additional Details

If no document is provided the action will continue on its way. This allows you to use the action without a bunch of action filters if the document is optional.

Sets the provided benevolence request attribute to the value provided.
Additional Details

The 'Use Blank Value' will determine what to do with the value you provide when it's blank. The default is to use it which will have the effect of blanking out any existing value.

This action will create a benevolence result linked to the benevolence request entity stored in an attribute. The result type must be stored in a Defined Value attribute, and the Result Amount must be stored in another attribute before you can use this action. You may optionally provide the "Next Steps" and "Result Details" attributes, as well as the "Result Summary" property as either a text string (which can be generated using Lava), or directly from the values other attributes.

Sets an attribute to a business based on a set of fields with the ability to also link a person to the business.
Additional Details

If the first 12 characters of the given business name and any one of the following match, it will match that business: Phone, Email, Street Line 1

If a record is matched it will be updated with the information provided from the workflow action.

The created/matched business will be put into the optional Business field attribute.

This action adds a new connection activity to the connection request referenced in the provided attribute. The type of connection activity and note can be provided as additional settings. The person attribute is the person doing the activity. The optional Connection Request Activity Attribute field can be used to store the GUID of the newly-added activity, for use in later actions.

Creates a new connection request.

Sets the connector for the provided connection request. Optional settings are provided for controlling whether an existing connector should be overwritten.

Sets the state of the provided connection request. Optional settings are provided for setting the future follow-up date.

Sets the status of the provided connection request.

Transfers the provided connection request to a new connection opportunity (of the same connection type).

This action creates a content channel item for the channel you specify. It can set the start date, expiration date (if applicable to your channel), the content and status. The title, dates, and content can use Lava to create dynamic values. You can optionally provide a workflow attribute in which to store the returned value of the created item, for use in later actions.

This action can also set any content channel item attribute values you provide. You can do this by providing the attribute key of the workflow's source attribute and the key of the content channel item's target attribute.

Creates and uploads a PDF contribution statement for a given person. You must either provide a 'Start Date' or an attribute that has the start date to use for generating the statements.
Additional Details

The statements will automatically be uploaded to the selected person record in the same way that the Statement Generator handles the files. The PDF will also be saved into the optional 'Document' attribute. This is handy if you want to use it in a subsequent workflow action.

The Document Person Key you provide will be what is shown to indivduals to describe what period the statement is for. In most cases this should be the year.

This action will create a short link for a designated page's URL. You can set the following parameters:

• Site Id or Guid: This is where you choose which site you want to use for the short link.
• Token: This is the value appended to the site's domain to make the short link unique. If left blank, a random token will be generated. Tokens must be unique in order for the short link to function correctly.
• Target URL: This is the URL the short link will redirect users to.
• Attribute: This is the attribute the generated short link's URL will be associated with.
• Random Token Length: This is the number of characters to use when generating a random unique token.
• Allow Token Re-Use: If a short link already exists with the same token, selecting Yes will update the short link with the new URL. Selecting No will result in the action failing because that short link already exists.

Temporarily pauses execution of the current activity until the set value is reached. The three value options are:

• Minutes To Delay: This delays for a set number of minutes.
• Date in Attribute: This delays until the Date in the selected Attribute is reached.
• Next Weekday: This delays until the next selected weekday (next Thursday, for example).

This action will present a person with a document that they need to sign electronically. The Signature Document Template must be configured in advance under Admin Tools > General Settings > Signature Documents. Person attributes can be used to define the person the document applies to, the person assigned to sign the document and the person who signed the document.

After the electronic signature is captured the person is asked to provide an email address so they can be sent a copy of the document for their records.

This action obviously sends an email of your design. It does have quite a few interesting options. The email can be configured to be sent to an email address you provide (multiple address can be separated by a comma) or the value of an attribute in the workflow. You can also add email addresses to CC and BCC fields. If you're using attributes to set any email address field, the attribute you provide must contain either a valid email address or the attribute must be of type Person or Group. See the Workflow Tips section of our Blasting Off With Workflows guide for a basic example of emailing a group using workflows.

If the Send To Email Addresses is a group or security role, you have the option of limiting the recipients of the email based on the group role attribute in the Send to Group Role field.

You also have the option of including up to three attachments. First, upload the file as a File type attribute, then select the workflow attribute that contains the file from the Attachment dropdown. The file size that can be sent is limited by both the sending and receiving email services, and is typically 10-25 MB.

The subject line, from address, and body of the email can contain Lava merge fields, so be creative. Also note that the email can be configured to be saved to the recipient's history.

In v14, we made have added new fields for From Name, this is displayed as the email sender's Name when the email is sentv14.1 If one is not provided and the From Email is derived from a Person then their fullname is used.

Writing the contents of a workflow email using Lava templates can be a little daunting. Also, many of these emails will be the same in similar workflow types. That's why you have an option to send an email using the contents of a system email. Just like the Send Email action, you can save the message to the recipient's history.

The system email shown on the list can be added from Admin Tools > Communications > System Communications.

This action is a bit different than most in that it is designed to continually check timeout parameters, therefore it never completes until a Unopened and/or No Action timeout occurs. Once the timeout occurs, it will complete and stop processing.

The first time it processes, it sends an email, and then creates two activity attributes. The first is a "DateTime Sent". It will set this to the time that the email was sent. It then checks this attribute in future processing to determine if it is the first process or not, and to evaluate timeout parameters.

The second activity attribute that is created is an "Email Status" attribute. This is used to store the last event status received by the Mandrill Webhooks.

During subsequent processing, this action will only check for timeouts.

If the "Unopened Timeout Activity" has an activity and "Unopened Timeout Length" has a value, it will check to see if status does not have "Opened" or "Clicked." If not, it will activate the "Unopened Timeout Activity" activity and then mark the action as complete.

If the "No Action Timeout Activity" has an activity and "No Action Timeout Length" has a value, it will check to see if status does not have "Clicked." If not, it will activate the "No Action Timeout Activity" activity and then mark the action as complete.

In addition to the action, the Mailgun.ashx and TwilioSendGrid.ashx webhooks have been updated to evaluate any events that occur for the email that was sent. When the webhook receives an event, it will attempt to find the corresponding workflow action and update the workflow action's "Email Status" activity attribute and then activate any configured activities.

When a Send event is received the attribute value will be updated to "Sent".

When an Opened event is received the attribute value will be updated to "Opened" (if not already "Opened" or "Clicked") and if an On Open Activity is configured, that activity will be activated.

When a Clicked event is received the attribute will be updated to "Clicked" and if an On Clicked Activity is configured, that activity will be activated

When a HardBounced, Rejected, SoftBounced, Spam, or Unsubscribe event is received the attribute will be updated to "Failed", and if an "On Failed Activity" value is set, that activity will be activated.

The above only applies if the workflow is still Active. Inactive workflows will not have events recorded.

The subject line, from address and body of the email can contain Lava merge fields, so be creative.

The Entity Attribute Set action can set any attribute value on any entity. It is a powerful action that should be used carefully as it requires a thourough understanding of how entities and their attributes are used in Rock.

The Entity Document Add action can add a given document to any entity. It's a powerful action that should be used carefully because it also requires a thourough understanding of how entities relate to the field types in Rock.

Additional Details

You will need to make sure that the Document Type you set is valid for the given Entity Type. Otherwise the action will log an error.

As seen in the Field Types section in this reference guide, if the field type represents a 'Full Entity' then that field type can be used as the "Entity Attribute" to get the correct entity. There is one small exception: We've eased the burden of converting the Person (picker) field type's PersonAlias into the underlying person entity so this action will do what you want.

The Entity Property Set action can set any property on any entity. It is a powerful action that should be used carefully as it requires a thourough understanding of how property values are used in Rock.

This workflow action will inactivate a given person's entire family, all of their families or only the individual.

The Multi-Family Logic setting controls exactly who is inactivated:

1. Inactivate individuals in the primary family
2. Inactivate individuals in all families
3. Inactivate just the individual

Additional action settings allow you to set the Inactive Reason and provide an Inactive Reason Note.

The Form action is one of the most powerful actions in Rock. It allows you to take input from a user and place it into the values of workflow attributes. Let's dive down into the details of this incredible action looking at each setting.

• Notification Email: This sends a selectable System Email Template out to the activity's assignee(s) when the action is reached during processing. This helps alert them that an entry step is waiting for them. This email can include links to the commands that are defined for the action. For instance, if one of the entry commands is Approve, you could include the approve link in your email so that the person could skip the step of visiting the form.
• Enable Note Entry: Enabling this will provide an area where the person can write notes in addition to the rest of the form. This is a great way for people to communicate with the next person in the process, or to track information that may not be stored as attributes.
• Enable Person Entry: Checking this box will cause the “Person Entry Configuration” section to appear within the Form configuration. Rather than manually creating individual workflow attributes for things like the person’s name, email, phone number or address, you can select what you want to ask and it will be added to the form for you automatically. You also have the option of asking for Spouse information. If the person or their spouse isn’t in Rock then this action will create a record for them. You can set the Person Attribute, Spouse Attribute and Family Attribute fields to store this information for either newly created or existing records, for use later in the workflow. On top of that, you can also enable Hide if Current Person Known to hide all the person entry fields if Rock already knows who the person is. Note, the fields will still show on the form if one of them is required and if that piece of information is not in Rock for the person.
• Form Header: This is a textbox that allows you to enter HTML combined with lava merge fields. This is a good place to add instructions for the user and help introduce them to the form they are about to complete.
• Form Fields: Next you'll see a list of all the workflow and activity attributes available. You can select which are visible, editable and required for the entry form. You can apply conditional logic to each field so that it only appears to the person if they give certain responses on other fields.
• Form Footer: Like the header, the footer allows you to enter HTML mixed with lava merge fields to help provide any closing content you would like.
• Commands: Finally, you have a list of commands to display at the end of your form. Each of the commands will be displayed as a button at the bottom of your form. The Command Label will be the label on the button. The Button Type describes what button style to use (these are defined under Admin Tools > General Settings > Defined Types > HTML Button Styles.) Next you can define an activity to run when the button is selected. This is very helpful for providing branching logic in your workflow. Finally, you can provide response text that the user will see when the action has been selected. Note that if a secondary form is available after the current form, this response text may not be shown. Instead the user will be taken directly to the second form.
• Command Selected Attribute: This optional setting allows you to insert the command label that was selected into the contents of an attribute. This is helpful when you're not activating activities from the actions.

This action allows you to select your Registration Template from the list of all of your templates, and generates a new random discount code that people can use when registering for an event using that template. You can use text or an attribute to determine the code length (minimum length of 3 digits), the amount (in percent or real value), how many times the code can be used (useful for "the first 100 registrants get a discount" type scenarios), the maximum and minimum number of registrants that the discount should apply to, and the date range in which the code is valid. It will store the resulting code in the Text type attribute you select in the last box.

Sets an attribute, which can be used elsewhere in the workflow, with the person's default account. If the person has no default, then the first saved account for the given person and given gateway will be used.

You can create a Group through this workflow action by providing the Group Type, Parent Group and a Group Name, which are required to create the group. You may provide the Group Name and Description as either a text string (which can be generated using Lava in the case of the Group Name), or directly from the values other attributes.

If the "Group Attribute" is configured, the newly created Group will be stored in that attribute.

Allows you to set or update a group attribute. You must have the group stored in a Group type attribute. The value can be set by text (which can be generated by Lava) or by the value of another attribute.

This action sets the selected attribute to a child group of the configured Parent Group that matches the selected Campus attribute. This action is useful when you need to find a matching 'campus' group that exists as a child of a particular parent group -- a common configuration in certain multi-campus group folder designs.

This action adds a person to a specific group that you select in the action settings.

Additional Details

Here's an overview of the settings available for this action:

• Group Member: An optional GroupMember attribute to store the group member that is added. v15.1

This action adds a person to a group provided via a workflow attribute. The default role will be used for the add. Optional parameters allow you to prevent the person from being added to the group based on the group's use as a security role, the group's type or its parent group.

This action will add a person to a group's attendance. You can also specify the date/time and location. There is also an option to add the person as a group member.

Additional Details

v13.6 Added the ability to optionally specify the Campus.

This action will update a group member's attribute with either a text value or an attribute. There is also the option to filter by the group role.

Adds a new note to a group member. The person must already be in the group for this action to work.

Additional Details

The Caption and Note fields are Lava capable so you can include something like this:

This is the note field for {% assign p = Workflow | Attribute:'Person','Object'%}{{p.FullName}} in
the {% assign g = Workflow | Attribute:'Group','Object'%}{{g.Name}} group.

...to create some very dynamic notes.

Removes the person from a group that is provided by a workflow attribute.

Removes a person from the group that is selected.

The Group Member Requirement Met action can be used to complete or "mark as met" any group member requirement. The "Person" field is used to set the person who marked this requirement as met. The "Group Member Requirement" field can either be the GUID of the group member requirement, or a workflow attribute for that value. The requirement will be set as manually met, and time-stamped with the time the workflow was run.

This action sets the selected attribute to a random group member. This action is useful when you need to assign a workflow to a random person in a specific group (e.g. for assigning requests). You can also filter by a Group Member Attribute.

Sets the group member's note property. Keep in mind that a group member can have as many 'Group Member Notes' as you'd like, but this is different. This is updating the note property on the group member.

This action updates a person's status in a provided group.

This workflow action is the reverse of Set Attribute to Initiator. It allows you to change the Initiator to the value of an attribute.

Will launch a selected job when executed.

Logs an error into the worflow's error log.

This action will run the 'Build Script' of a Persisted Dataset and update its value through using the provided Persisted Dataset's 'Access Key'.

If you select Delay Processing Until Complete, the action will wait until the persisted dataset is done being updated. Otherwise it will trigger the update to begin then continue before it's complete.

Allows you to update a person's address based on a provided location.

Additional Details

Here's an overview of the settings available for this action:

• Person: This is the workflow or activity attribute that contains the person whose family address should be updated.
• Location Type: If an attribute is entered for the Location Type (From Attribute) setting, this value will first be checked to see if there is a valid location type specified. If so, it will be used to determine the location type to update. If it is not specified, or is not valid, the Location Type setting will be used to determine the location type to update.
• Location: The address to set the person's family address to can either be entered explicitly or set from a workflow or activity attribute. If the address is not being read from an attribute, enter the address in this field.
Location (From Attribute): If you'd like the address to be set from one of the workflow or activity attributes, select the attribute here. This will only be used if the Location field is blank.
• Is Mailing Location: If you'd like to update the flag that determines if the address is a mailing location, you can enter a value here, or select an attribute. The value you enter or the value returned by the attribute should be either 'True', 'Yes', 'False', or 'No'. Any other value will be ignored.
Is Mapped Location: If you'd like to update the flag that determines if the address is a mapped location, you can enter a value here, or select an attribute. The value you enter or the value returned by the attribute should be either 'True', 'Yes', 'False', or 'No'. Any other value will be ignored.

This action will take a first name, last name, email, mobile number and birthday and search for a matching person in the database. The result will be placed into a selected attribute. If no person was found a new record will be created for you. If a match is found, it does not update the person record with any of the supplied values except the email address if enabled by the action setting.

Additional Details

The record with the highest score greater than 35 points is selected as the match (if no records score more than 35 points a new record will be created).

• First/Nick Name match = 15 points.
• Last Name match = 15 points.
• If Last Name doesn't match but previous name does = 12 points.
• Mobile Phone OR Email match (or both) = 15 points.
• Month/Day match with the birthdate = 10 points.
• Year match with the birthdate = 5 points.

Other similar routines (presumably registration, etc) in Rock also consider:

• Gender Match = 3 points
• Suffix Match = 10 points

Sets the selected person attribute of the person contained in a workflow attribute to either text you provide or the contents of another attribute.

This action uses two Person attributes to add a single person to a different family. The person will be added to the family of the person in the 'Add to Family With' attribute.

You can optionally assign a Role (Child or Adult) to the person being added using either a fixed value or a 'Group Role' attribute for the Family group type.

The person being added to the family can either remain in their old family or be removed from it, using the 'Remove Person From Current Family' setting.

This action allows you to set a person to follow a designated entity. The "Entity To Follow" field is where you enter an Entity Id or an attribute that contains the person or group to follow. This field supports Lava.

Additional Details

If you are trying to mimic what happens when a person follows another person (by clicking their photo), the Entity Type should be set to "Person Alias" and the Entity To Follow must be set to the followee's PersonAliasId.

In v13, we made this easier to do. When the Entity Type is "Person Alias", if your Entity To Follow attribute holds a Person (field type), Rock will automatically use the PersonAlias Id from the fieldtype instead of the usual PersonAlias Guid (which would not otherwise work). v13.0

Use this action to find Campus Team members and place them in a workflow attribute for use in later actions. You can provide a person attribute to find team members at that person’s campus.

If a campus attribute is provided, only team members from that campus will be returned. The campus in this attribute will be used regardless of the person’s campus, in cases where both attributes are provided.

By providing a person and a group, you can determine if that person has any attendance in that group and when they last attended. This information is stored in the attributes for Attended Boolean and Last Attended date for use later in the workflow.

By providing a person and a group type, you can determine if that person has any attendance in groups of that type, and when they last attended. This information is stored in the attributes for Attended Boolean and Last Attended date for use later in the workflow.

This action takes the person identified in a Person type attribute and looks up the person considered their "Head of Household" (typically the oldest male). The Head of Household person will be stored in another Person type attribute.

Returns the person's spouse to a selected workflow attribute. When determining the spouse the action will look for an adult in the same family who is of the opposite gender and married. If more than one person is found then the first person will be returned.

Sets the configured Boolean workflow attribute to True or False depending on whether or not the configured Person is in the selected Data View.

This action adds a note to a person record. Optionally, you can set a caption, set the note author or mark the note as an alert.

Updates a person's phone number.

Additional Details

Here's an overview of the settings available for this action:

• Person: This is the workflow or activity attribute that contains the person whose phone number should be updated.
• Phone Type: If an attribute is entered for the Phone Type (From Attribute) setting, this value will first be checked to see if there is a valid phone type specified. If so, it will be used to determine the phone type to update. If it is not specified, or is not valid, the Phone Type setting will be used to determine the phone type to update.
• Phone Number: The phone number to use when update the person. The number can either be set explicitly or set from a workflow or activity attribute.
• Unlisted: If you'd like to update the flag that determines if the phone number is an unlisted number, you can enter a value here, or select and attribute. The value you enter or the value returned by the attribute should be either 'True', 'Yes', 'False', or 'No'. Any other value will be ignored.
• Messaging Enabled: If you'd like to update the flag that determines if the phone number has messaging (SMS) enabled, you can enter a value here, or select and attribute. The value you enter or the value returned by the attribute should be either 'True', 'Yes', 'False', or 'No'. Any other value will be ignored.
• Ignore Blank Values: If you do not specify a phone number, or you are setting the phone number from an attribute and that attribute is blank, this flag indicates if the phone number should be updated to a blank value or not.

Updates a property (name, email, connection status, etc.) of a person. This action will work with either a value you provide (Lava enabled) or an attribute value. When providing an attribute the value in the drop-down gives you a hint as to what type it should be. See the 'Additional Details' section below for more information.

Additional Details

Here's a couple of other tips to help you with this powerful action.

• When dealing with a property that is a defined value (like 'Title') you may either provide it with:
  1. An attribute of type Defined Value
  2. The Guid of the defined value
  3. The string representation of the defined value (e.g. 'Mr.')
• With properties that represent Enums (like gender). You can provide either the Enum as a string or an integer. The valid values are listed in the drop down.

Adds a person, stored as a person attribute, to the provided Organization Tag. If the supplied tag does not exist it will be created.

Like the Person Tag Add, this action removes a person from an Organization Tag.

This workflow action will add a Prayer Request for a person. The attribute values you provide related to the request, like the Category or Public options, will be included in the Prayer Request that's added.

It's important to note that you can provide the requestor in one of two ways:

1. As a person object through the entity passed to the workflow, or a standard workflow attribute that references a Person.
2. By providing a first name, last name and email address. If you choose this approach, you have additional options. If Person Matching is enabled then you can use the information to create a new person record, or match to an existing record. Or, you can disable Person Matching entirely to prevent the request from being linked to a person's record.

Processes a payment from a saved account. The saved account to use can optionally be set using the Get Saved Account action.

If you have a Firebase app for Rock, this action will let you send a notification to users. You can send it to either a person or a group.

This action takes the user to a different screen after the workflow action is complete. You can set the action to redirect to either a URL or a URL Attribute.

The Processing Options field allows you to set how the workflow should continue:

• Always continue: Sets the workflow to continue processing regardless of the redirect status or if the action is running in the background
• Only continue on redirect: Sets the workflow to only continue processing when the redirect is successful
• Never continue: The action will never complete and the workflow will not continue processing until a filter is used to skip it

This action adds a reminder to the provided person's record. You can set the note text, the date for the reminder, how frequently the reminder is repeated, and how many times to repeat the reminder.

This block provides a large Lava editor for writing into an attribute.

This workflow action will create either a one-time or weekly schedule. Settings can be hard-coded or set using the values of other attributes. If a name is provided for a one-time schedule, this will make it a "Named Schedule" which will appear in certain places in Rock where named schedules are shown.

If the "Schedule Attribute" is configured, the newly created schedule will be stored in that attribute.

Additional Details

• Adding a Name will make it a "Named Schedule" so it will appear in certain places in Rock where named schedules are shown.
• The "Weekly:" settings will not work for Sign-up Groups/Project Opportunities.

While the name of this action is fairly descriptive, it may not be clear as to when you would use it. This action sets the contents of an attribute to either text you provide or the contents of another attribute. The power of setting it to text is that you can use Lava merge fields. This allows you to string together one or more attributes using Lava’s powerful formatting functions.

Setting an attribute to the contents of another attribute might seem a little redundant. However, there are times that you might expect an attribute value to change and you want to keep a copy of its previous value.

This workflow action will create a sign-up project opportunity. All settings can be set using the values of other attributes, with some allowing hard-coded values.

Note that the allowed location and schedule types for the new opportunity will be limited by the types allowed on the specified project's group type. Weekly schedule types are not compatible with sign-up projects, and will not be allowed regardless of whether they're allowed by the group type.

This action creates an SMS Response message with the From and To number you specify.

For example, say you have a text-to-workflow set up to handle certain incoming keywords. With SMS Communication Process Response, if no keyword is found, the workflow injects the message into the person-to-person text system.

Additional Details

If the SMS system returns an error, the error message will be placed in the Error Attribute. Currently, the only error that would be returned is the standard 'Could not deliver' message. Consider checking to see if the value is non-blank, and if so, send it as a response to the user.

This action is very similar to the Send Email action but it sends a SMS text message instead. This action assumes there is a valid SMS text subscription available. See the Communicating with Rock manual for more details on SMS text message configuration.

You can also include an attachment. To include a dynamically generated attachment (for example, a contact card), use the Set Attribute From Lava workflow action.

Additional Details

Either the From field should be set with a SMS From Number or the corresponding From (From Attribute) of type DefinedValue should hold the selected SMS From Number. v12.5

The Run SQL action is one of the most powerful actions in Rock workflows. It allows you to execute any SQL query you provide and store the results into an attribute on the workflow. This action is great for looking up data in the database and using it to make decisions in the workflow.

Additional Details

Note that the SQL you provide can contain Lava merge fields to help pass in attribute values for your SQL. Consider this example.

Say you wanted to get the gender of the person stored in the attribute Requester. You could use the SQL below to achieve this.

DECLARE @PersonAliasGuid uniqueidentifier = '{{ Workflow | Attribute:'Requestor','RawValue' }}'
SELECT [Gender] 
FROM [Person] p
INNER JOIN [PersonAlias] pa ON pa.PersonId = p.Id
WHERE pa.[Guid] = @PersonAliasGuid
--note gender is stored in the database as a number where 0 = Unknown, 1 = Male and 2=Female 

When the action places the result of the SQL into the configured workflow attribute, the returned result must match the data type of the attribute. For instance, your SQL can not return text if the attribute configured is expecting a number. A few common attribute types that you will use often are listed below, each with what they are expecting as input.

• Boolean: True/False
• Person: Guid of a person alias
• Group: Guid of a group

Note: If you update something directly via SQL, the cache manager won't know about it so you'll need to take care of flushing it from cache yourself.

You can add a Step to a person’s record through a workflow by providing the Step Type, Step Status, Start Date and End Date. As with other workflow actions, you can alternatively use Attribute Value selections. You can optionally provide a workflow attribute in which to store the returned value of the created Step, for use in later actions.

Note that the workflow will encounter an error if you try to use a Status that doesn’t apply to the Step Type.

Additional Details

• Campus (optional): The campus where the step was completed. v10.3

Takes an existing registration code (as text) and updates the amount of the discount that it gives. You can optionally have this affect past registrations which used that discount code, in addition to new registrations.
Additional Details

Be careful using the "Update Past Registrations" option- remember that people will have been told the total amounts that is due (and received a confirmation email proving it), and that if you set this to "Yes", that you're changing that amount on them in mid-stream and with no (automatic) notice. Personal contact is going to be key, if you find you have to do this.

This action will make a Get, Post, Put, Delete, or Patch request to the web address you specify. You can provide any number of parameters or headers, optionally provide a username/password set of credentials, specify the request and response content type, and provide the body of the request. The action will make the request and store the response as text in the attribute you specify.

This action will add a new workflow note. The note property has the ability to customize the message using Lava. You can also customize the formatting of the note by selecting the Note Type. More on using workflow notes is discussed in the Workflow Notes section of the workflow guide.

This is the Game Over action that marks the entire workflow as complete. No other activities or actions will be processed.

Simply put, deletes the current workflow instance.

This action allows you to display a large amount of information in the WorkflowEntry block, typically on the screen that appears after a person completes and submits a Form action. The HTML field takes either HTML or Lava, which means you have a lot of control over the formatting and display of the content.

See the section on persistent vs. non-persistent workflows to get a deeper understanding of this topic. This action marks the current workflow as persistent.

There is an optional parameter called Persist Immediately. Normally this action will cause the workflow to be persisted (saved) once all the current activities/actions have completed processing. Set this flag to true if the workflow should be persisted immediately. This is only required if a subsequent action needs a persisted workflow with a valid id.

This action will set the campus of the workflow using the given Campus attribute or the primary campus of the given Person attribute. If both are given, the Campus attribute will be used. If neither are given, the action will return an error.

This action will set the name of the workflow. This name will appear in the various workflow lists you use to manage and process your workflows. The text field of this action can use Lava merge fields to help you craft effective names. Many times these names will simply come from an attribute value that is entered through a user entry form.

This action sets the status of the workflow. The workflow status is simply a text field so you can set it to any value you choose. This field supports the use of Lava merge fields.

This action allows you to set the status of a different workflow. The workflow status is simply a text field so you can set it to any value you choose. This field supports the use of Lava merge fields. You can also query for the status using SQL commands. The "Process Target Workflow" option allows you to decide whether or not to run the targeted workflow after its status is set.