Implementing Flow Based Actions

Flow based actions bring lots of benefits for the customer which allow more flexibility for them without requiring Bullhorn to amend or enhance the product.

They can easily override packaged actions to:

• Add custom validation
• Add custom field inputs to Screens within a Flow
• Perform custom operations as part of an action
• Reuse packaged actions & components

Action Lifecycle: From Trigger to Execution

• Orchestration
• Actions can be triggered from several different contexts in BHRC, including:
• Record pages
• Job A job (vacancy, position, role) is an opening for which a customer's client needs a placement. ATS
• Candidate A person looking for a job. A candidate can also be referred to as a Job Seeker, Applicant, or Provider. ATS
• List Views
• Omnitable Generic/reusable component that can be added to pages to show a fully configurable/customizable list of records and actions.

Each of these contexts has its own known set of data, e.g. the id of the contact record displayed in the record page, or the list of application ids selected in the ATS.

If we flip this around, each action does not necessarily care about the context it was invoked from (although some will). For example, sending an email needs to know about the Contact, not the application ids.

This leads A record that holds a potential relationship with a person or company. Examples: candidates, contacts, companies, jobs. to using orchestration so that we can reuse data preparation and action flows in different contexts.

Each invocation point for a specific action defines its own Contextual Action When used in ATS or Search and Match UI, one of multiple actions available after user has selected a sub-set of Candidates Flow.

This is composed by using a Data Preparation subflow to transform the context (invocation point) specific data to a more generic set that can be used for different actions. For example, both “Send Email” and “Add to job” would need the Contact details.

Then, the Contextual Action Flow passes the output from the Data Preparation Flow into an Action Execution Flow. As this is now being passed the data it cares about, it can be reused in different orchestrations for different contexts.

So:

• A Contextual Action Flow (or Contextual Flow) is for a given context performing a specific action. It takes context specific input and invokes an appropriate Data Preparation Flow followed by an Action Execution Flow
• A Data Preparation Flow (or Data Flow) takes context specific data and turns it into a standard set of details many actions care about. Data Preparation Flows can be reused for different actions from the same context
• An Action Execution Flow (or Execution Flow) accepts action specific data, and performs a given action which could be common to many contexts. Action Flows can be reused from different contexts..

Naming Conventions

We will also want to adopt an actual flow naming convention (for both API API, or Application Programming Interface, is used by customers to create custom career portals or to take advantage of Data Mirror/DataMart. Bullhorn prefers to use REST API. names and labels) to make it easier to understand the roles A job (vacancy, position, role) is an opening for which a customer's client needs a placement. of these flows.

• Contextual Action Flow => “CAF Action (Invocation Point)”

• Data Preparation Flow => “DPF Data Description”

• Action Execution Flow => “AEF Action Description”

Packaging

The long term goal is to wrap every action in this fashion. This means packaging each of these flows.

In the short term, where we want to move to this architecture to allow for customization, we might package fully fledged Contextual Action Flow and Data Preparation Flows, but only a thin Action Execution Flow that the customer can override and implement their own logic. Ideally, we would implement and provide the real action inside the Action Execution Flow, but as we are first targeting the actions that need to be customised, the initial delivery would not be used anyway, so we can defer that.

Omnitable will always use flow-based actions.

Customization

Each and every flow will be overridable. This gives customers the opportunity Potential sales to new or established customers. to replace or enhance only the parts they need to.