The Business Action Module is a configuration module, not a module that is actually designed. It’s not for users, it is for administrators and will permit us to manipulate or manage all the action buttons and links that are in coreBOS in a very easy way.

A business action is the definition that something graphical has to appear on the screen or not. After choosing the type of action you want (button, link), then you link the action to a business rule, and the condition is based on a map which may be a SQL query. Most of the script is executed using actions (launcher actions). Business actions are written just once they can be used every time and are built inside the module.

The usage of a considerable number of Business Actions and script weakens the system performance, you lose control of the system. It must be done in different infrastructure.

Basically up to the creation or addition of this module in order to add buttons in the list view or in the detail view you had to program. In this way you could manipulate almost all of them(not all of them because there were a set of actions that were hard-coded in the templates,so you actually had to go the code to change them).

Now all the actions have been moved out of the templates; they have been moved into business actions, then changed the vtlib API so it keeps working with, but calling out no business action model.

That permits any administrator user to actually add new links or eliminate links simply by adding records in coreBOS as we can do normally.

This also gives us the power to report on and search all that stuff.

 

 

So for example if we go to the Business Action Module and we ask for the actions that are on the Invoice module, we see that there are 4 Business Actions.

There are 3 on the Detail View of the Invoice Module, exactly Add Payment, Send Email with PDF, Export to PDF and we have a header script which is loading specific JavaScript up to this Module.

 

 

So if we go to the detail view of the Export to PDF business action and delete it, the business action will not be shown anymore in the detail view of the Invoice. That is really that simple, to be able to actually manipulate these actions.

We can edit a particular Business Action and for example not show to all users, but determine a specific user. That specific user is the only user that we want to be able to see this action or any user in the roles specified.

Or we can take that further and use a business rule map.The business rule will actually permit you to set conditions like: if I want to add tickets on a project but only if the project is open, then you can create a business rule map where you set the condition to return true or false depending on the status of a project, if it’s true or false and then the action will be shown or not depends in that condition.

As you can see it’s not only about being able to easily add or delete actions,but actually is about being able to set conditions (advanced conditions) about these actions.It is really a powerful little feature.

 The Launcher Actions

These actions are usually used when a user builds an action based on a script designed by a programmer in a certain language.

When designing a Launcher Type Action is important to define the name of the action, the type of the action that we are creating. The type of business action may be script launcher Create/Update Entity, Alert etc. In business actions is also required to assign a user that this action is dedicated.

In creating business actions each action is important to create maps in order to define the input and output for performing actions. Also this action contains business rules that include all the roles and groups of user that is action is dedicated to.

Send Mail Actions

The map is important in business action because you can put the main parameters of the script (Subject, record id, assegnato a…). When you use the type of action Send Mail another step that is going to be taken Message Setting. In message setting we put the address of the person who is going to receive the email, the variables you have to be fulfilled they take values from CRM fields and they also have values from the actual module and the related modules. Normally we create actions using workflows. You put at the workflow the condition of how and when the action is going to be executed. In this way, you can make the operations automatic. Causale field is used as a logical identifier of an action.

Create Entity Action

The create Entity Actions build actions of two related modules the origin module and the target module. In this type of actions is important to define the related fields on modules in the map that takes the input and output parameters.

Sequencer Action

These types of actions are related with the sequencer module. Sequence actions execute each action one by one. The sequence action don’t execute if we don’t connect it with a primary actions. The field business rules in sequencer actions is important because defines the users when this action will be performed. When we execute the sequence actions all the actions that contain the sequencer will be executed.

Workflow Integration

Business Actions are not just about hiding and showing actions. They have really powerful features. One of these is the workflow integration.

So let's say for example we create a new Workflow. For that, we access Workflows and select the module we want this workflow to operate on, for example, Support Tickets.

 

 

We are going to create a workflow that updates the Assigned to. The workflow will run every time the record is saved with no conditions.

We are going to add an Update Field task, which will set the field Assigned to every time that a new Support Ticket record is saved to testes users.

 

 

If we go to the Support Ticket, we can see that every time we create a new record it will be assigned to the testes user.

 

Now, if we go to the workflow and change the launch condition to System, we can see that the Assigned to field won’t be changed into testes. It doesn’t do anything.

That’s because the System condition has to be manually launched. So you have to trigger it from some other source. So what sources can that be?

Well, a way of triggering it is by using a link. 

So, let’s go to the Business Action Module and create a new action.

It is going to be a DETAILVIEWBASIC. We must write a link label, for example: Assigned to testes.

 

 

The link URL is going to be this little code:

javascript:ExecuteFunctions('execwf', 'wfid=39&ids=$RECORD$');
location.reload();

 

Be careful to update the wfid with the workflow id showed on the link URL.

 

 

Now, if we go on the Support Ticket Module and click on a record, we can see that a new Action is presented, the Assigned to Testes action. If we click on it, the user will get assigned to testes user.

 

 

Mass edit 1x1

If you go to the list view of any module, you will see the mass edit button with allows you to edit several grouped records with the same value. So in this sense, this record should be logically grouped, because, in the end, they are taking the same value.

But there may be cases when we would want to get the same mass edit option, but in our case to let us do mass edit 1x1. We can do that using a Business Action.

Let’s go to the Business Action module and create a new action.

This action will operate on the LISTVIEWBASIC. Give it a label like massedit 1x1.

On the link URL copy the following:

javascript:mass_edit1x1();

Don’t forget to set the Business Action to Active.

Click Save.

Now if you go for example to the Lead module a massedit 1x1 button will be shown.
 

 

If you select some records and click on the massedit 1x1 button, you will be shown the following window when you can edit the selected records 1 by 1.