USER HANDBOOK. visuallifecycle professional. Last updated: August 20, 2014

Transcription

1 USER HANDBOOK visuallifecycle professional Last updated: August 20, 2014 Apracor GmbH Adams-Lehmann-Str München Sitz: München Amtsgericht München HRB Geschäftsführer: Levin Beicht, Christoph Eschweiler

2 Contents Introduction... 4 Key Features... 4 Installation... 5 Configuration... 8 User Profile Configuration... 8 Visualforce Page Permissions... 8 Apex Class Permissions... 9 Visuallifecycle Custom Object Permission... 9 Object Configuration... 9 Visualforce Page Configuration... 9 Custom Objects Quick Start Creating a new process Defining the Object s Lifecycle Defining states Defining actions Customizing the user interface Example Scenario Business Situation Parties Involved Salesforce Setup Basic Workflow Component Description Process Usage Process Wizard Usage Example Process Guide State/Status, Status Field and Status Value Field Permission Action Usage Conditional Actions

3 Action Field Permission Field Update Object Create and Object Create Field Process, State and Action View Translation Picklist Filter Working with a Process Formulas Operators Functions Miscellaneous functions Mathematical functions String functions Date/time functions More examples Appendix List of Figures List of Tables

4 Introduction Thank you for your interest in visuallifecycle! With visuallifecycle you can take back the control over your salesforce processes. Visuallifecycle enables a salesforce organization to visually define and implement their business processes directly in salesforce without the need for any coding. It supports the end users in following these process with an improved but familiar user interface, which prevents any misuse and shows only context sensitive information to the user. This reduces training time for end users, improves data quality throughout the system and guarantees process compliance, so every customer is treated with the same high standards. Key Features Visuallifecycle professional comes with a large amount of built-in features that help you to optimize your process experience in Salesforce. The following list briefly highlights some of the most important features. Graphical process design 1 : With the Process Wizard, you can literally draw your business processes directly in Salesforce. ou just add process states and connect them with each other. And the best thing is: After you saved your process, it is already read to be used by your users! Visual Process Guidance 2 : ou have thought-out and complex processes and you want to ensure your users never get confused about where in the process they are? To help you solve that issue, we developed the Process Guide. The Process Guide is a visual representation of the current process status for your users, ensuring they always stay on top! Custom permissions 3 : ou can set up different visibility, processability and necessity for each and every field throughout the entire process. By leveraging this feature you can simplify forms for your users and only show information that is relevant to them, thus vastly improving your overall data quality! Conditions 4 : Sophisticated and elaborate business processes often require decisions to be made. Visuallifecycle professional comes with a built-in logic to fully integrate logical conditions into your Salesforce process. ou just specify the criteria and visuallifecycle evaluates it for each and every process lifecycle! Automatic data updates 5 : visuallifecycle professional comes with options to fully automate updates to your data while your users work through your process. By using automatic field updates, your data can be updated using even the most complex formulas! Automatic object creation 6 : Sometimes proceeding with one process requires to start another. Visuallifecycle professional gives you that possibility out of the box. Just specify what object should be created when and you re done! our users don t need to do a single click they just proceed through the process as usual! Translation 7 : ou work in an international environment and have a multi-lingual workforce? That s not a problem for visuallifecycle. The application has built-in translation options for processes, ensuring your users always see their information in a language they understand! 1 For more details and screenshots see chapter Process Wizard 2 For more details and screenshots see chapter Process Guide 3 For more details see chapter Field Permission 4 For more details see chapter Conditional Actions 5 For more details see chapter Field Update 6 For more details see chapter Object Create and Object Create Field 7 For more details see chapter Translation 4

5 Installation Visuallifecycle professional should be installed from the AppExchange 1. After selecting to install visuallifecycle, review the package installation information (see Figure 1) in your organization and press continue. Ensure your organization name, edition and installing user are correct (shown red in the figure below). Don t forget to accept the terms and conditions. Note: The version number might be different. FIGURE 1: VISUALLIFECCLE PROFESSIONAL PACKAGE INFORMATION Next, please review the package details (similar to Figure 2 below). After you are done, click continue again. FIGURE 2: PACKAGE INSTALLATION DETAILS 1 Get it from: 5

6 Now the actual installation routine starts. Please review and approve the package API access by clicking next. FIGURE 3: VISUALLIFECCLE API ACCESS REQUEST The next step is about granting the proper access to the application. Please choose the security level for the application in the screen, similar to Figure 4 below. For smaller organizations it is recommended to use Grant access to all users, to enable all users to work with the application right away. If you want to restrict the access to the application please choose Select security settings and exclude all the profiles you do not wish to have access to your processes. Note: These users will not be able to access any objects which are enabled for processes by visuallifecycle. For more details, please see the next chapter. 6

7 FIGURE 4: VISUALLIFECCLE SECURIT SETTINGS The last step simply requires you to re-confirm the package installation. To do so, click the install button on the screen similar to Figure 5. FIGURE 5: FINAL INSTALLATION STEP The installation might take some time. ou will receive a message indicating that an will be sent to you as soon as the installation has finished. After you received the , the package installation is complete. ou can now proceed with the package configuration. 7

8 Configuration User Profile Configuration All users that are supposed to be working with visuallifecycle enabled objects need the option API Enabled activated in their profile. ou can modify the profiles by navigating to your organization s setup screen, click Manage Users and Profiles. Select the appropriate profile and enable the option. Please see the official Salesforce documentation for more information about right management. Note: We recommend that process administrators has access to all of these pages, all Apex classes and read/write access to all visuallifecycle custom objects. Visualforce Page Permissions In addition to API access, users also need access to the following Visualforce Pages. Table 1 shows a list of all Visualforce pages in visuallifecycle professional. Additionally you can see for whom each page is relevant. If a page is relevant to a process administrator (i.e. someone who creates and manages the process itself) or a process user (i.e. someone who uses a process the process admin set up). ou can set the permission to these pages respectively. Page Name Process Admin Process User vlc_pro.accountdeletepage vlc_pro.accounteditpage vlc_pro.accountnewpage vlc_pro.accountviewpage vlc_pro.actioneditpage vlc_pro.actionfieldupdateeditpage vlc_pro.actionfieldupdatenewpage vlc_pro.actionfieldupdateviewpage vlc_pro.actionnewpage vlc_pro.actionobjectcreateeditpage vlc_pro.actionobjectcreatenewpage vlc_pro.actionobjectcreateviewpage vlc_pro.actiontranslationeditpage vlc_pro.actiontranslationnewpage vlc_pro.actiontranslationviewpage vlc_pro.actionviewpage vlc_pro.casedeletepage vlc_pro.caseeditpage vlc_pro.casenewpage vlc_pro.caseviewpage vlc_pro.contactdeletepage vlc_pro.contacteditpage vlc_pro.contactnewpage vlc_pro.contactviewpage vlc_pro.fieldpermissioneditpage vlc_pro.fieldpermissionviewpage vlc_pro.leaddeletepage 8

9 vlc_pro.leadeditpage vlc_pro.leadnewpage vlc_pro.leadviewpage vlc_pro.opportunitydeletepage vlc_pro.opportunityeditpage vlc_pro.opportunitynewpage vlc_pro.opportunityviewpage vlc_pro.processadmineditpage vlc_pro.processadminviewpage vlc_pro.processbuilderpage vlc_pro.processeditpage vlc_pro.processexportpage vlc_pro.processimportpage vlc_pro.processnewpage vlc_pro.processstatuseditpage vlc_pro.processstatusnewpage vlc_pro.processstatusviewpage vlc_pro.processtabpage vlc_pro.processviewpage vlc_pro.statuspicklisteditpage vlc_pro.statuspicklistviewpage vlc_pro.statustranslationeditpage vlc_pro.statustranslationnewpage vlc_pro.statustranslationviewpage TABLE 1: VISUALFORCE PAGES AND THEIR USERS Apex Class Permissions There are two Apex classes you can configure the permissions for in the profile screen: vlc_pro.process- BuilderController and vlc_pro.processinstall. Both classes are for the process administrator. At least they need access to these classes. Visuallifecycle Custom Object Permission All process administrators need full read and write access to all custom object from within the visuallifecycle package. The objects are: Actions, Field Permissions, Field Updates, Field Values, Object Creations, Object Creation, Processes, Process Administrators, States, State Fields, State Histories, State Picklist Filters, Translations (Action) and Translations (Status). Object Configuration Visualforce Page Configuration Each object you want to enable for visuallifecycle needs the default view, edit and create pages to be overridden. To do this, go to Setup Customize and select the object you want to enable. Then select Buttons, Links and Actions. The screen should look similar to Figure 6 below. 9

10 FIGURE 6: OVERRIDE BUTTONS, LINKS AND ACTIONS Click the edit link for the view page. The upcoming form provides you with a convenient way to override the default pages (see Figure 7 below). FIGURE 7: OVERRIDE VISUALFORCE PAGE Select Visualforce Page for the option Override With and choose the appropriate View Page from the drop down, e.g. for the case view page: vlc_pro CaseViewPage. The technical name in square brackets begins with vlc_pro. See also X Click save and repeat this for Delete, Edit and New actions. The object is now properly configured for the use of visuallifecycle. Note: Until there is a valid process defined, the object will behave exactly as before. 10

11 Custom Objects If you want to configure visuallifecycle professional to be able to create processes for your own custom objects, you just need to perform a few simple steps. ou need create Visualforce pages to override the default view, edit, new and delete pages and then assign them as you would do for a standard object. Creating a Visualforce page is done by simply cloning an existing standard page. In the following sections the respective pages are cloned for a custom object Purchase c. To clone a page, navigate to Setup Develop Pages and click on CaseViewPage. Click and highlight the complete Visualforce Code as shown in Figure 8 below. FIGURE 8: SELECTED VISUALFORCE CODE FOR CASEVIEWPAGE Right-click the selection and copy the code and go back to the listing of Visualforce pages. Click the new button. Past the code in the Visualforce section of the upcoming edit screen (see Figure 9 below) and change the name of the standard controller to Purchase c (or whatever you custom objects name is). Specify a label, e.g. View page for a Purchase and a name, e.g. PurchaseViewPage and click save. Repeat these simple steps for your edit, delete and new page. Simply open the respective Case page, copy the Visualforce code and paste it into a new page. 11

12 FIGURE 9: NEW VISUALFORCE PAGE FOR CUSTOM OBJECT After you are finished creating the pages, navigate to your custom object configuration by clicking Setup Create Objects and select your custom object. In the section Buttons, Links and Actions click edit next to the view page (see Figure 10 below). 12

13 FIGURE 10: BUTTONS, LINKS AND ACTIONS FOR A CUSTOM OBJECT Now you see a screen as previously shown in Figure 7. Select the option Visualforce Page and then select the appropriate page from the picklist (see Figure 11 below). Repeat this for the edit, new and delete page. Afterwards your custom object is ready to be used with visuallifecycle! 13

14 FIGURE 11: OVERRIDE VISUALFORCE PAGE FOR A CUSTOM OBJECT 14

15 Quick Start This chapter is supposed to provide you with a quick guide to get you started with visuallifecycle. It is however not a comprehensive explanation of each feature. To get detailed information about the features, we suggest you take a closer look at the chapter Component Description and its sub-chapters. Creating a new process To define a new process open the visuallifecycle app and go to the Processes Tab. Here you can see all processes in your organization are displayed. To create a new process click the new button. In the new process screen provide the process name, the object for which you want to create a new process and click Continue. If there is more than one record type available on this object choose the record type and press Continue. Note: ou can create one process for each object record type combination. Finally select the status fields that define the status of your object in its lifecycle by pressing the > button and press Save. An object s status is a defined step in an object's lifecycle. It can consist of many different kinds of information. A case for example, a process state could be comprised of the status picklist (Open, Closed, etc.), priority (High, Medium, Low), an incoming channel ( , Phone), a product line, and many more. For more information on states and status values, please refer to the respective chapter in this document. Note: Only picklist objects can be used to identify a state, since they are the only objects having a predefined set of values. ou will be taken to the process view page. As this process is new, there are no defined states yet. Defining the Object s Lifecycle To define the state flow click the Process Wizard button on the top of the process detail page. This will take you to the Process Wizard. An object's lifecycle consists of two main elements: states and actions. A state, represented by a box in the process builder, is a defined step in the object's lifecycle and an action, represented as an arrow, is a transition between two of these states. 15

16 Defining states The Process Wizard consists of two elements. The central layout pane hosts your defined lifecycle, while the right part of the screen shows details of the selected elements. In the Process Wizard click the New Status Button to create a new Status. In the detail pane on the right, you will see three sections. The top contains the status' name. The Status Values section contains the process status fields you defined earlier. Here you can assign a value to each of these fields. Whenever an object has these values set to these fields, it is considered as being in this status. The Status Detail section contains various options that describe the behavior of this status. Start State: If this option is selected this status is defined as a starting point for your process. If there are more than one start states defined, the user can choose on object creation, where he wants to begin. Editable: This option defines if the object can be edited in this state. For example, this can be used to prevent the user to change data on a closed case. Deletable: This option defines if the object can be deleted in this state. Press the done button to save the status details. On a selected state in the layout pane, you have three options: The pencil symbol changes to edit mode, so you can edit details of your status on the right. The gear symbol activates or deactivates a status. An inactive status cannot be used and no actions towards this status can be executed. The trash bin symbol deletes the status. Note: All states are created as Inactive and must be manually activated before they can be used. 16

17 Defining actions To define an action, select the state from which the action should be accessible. Then click on the blue arrow on the right of the status and finally click on the status this action should connect to. A new action is created and you can give it a name in the detail pane on the right. Press the done button to save the action. On a selected action in the layout pane, you have three options: The pencil symbol changes to edit mode, so you can edit the name of your action on the right. The gear symbol activates or deactivates an action. An inactive action cannot be used. The trash bin symbol deletes the action. Finishing up Once the lifecycle is properly defined click the Close button on the upper right corner of the Visual Process Builder. ou are taken back to the process view page and can see the changes you have made to your process. Note: All these changes are reflected instantly in the system, and the users can work with these new states and actions right away, once they are activated. Customizing the user interface For each separate state in an object s lifecycle it is possible to further customize the user interface the end users are going to see. Each field on the object can be configured to be visible, editable and mandatory for each state. For more information about this feature, please refer to the respective chapter within this document. To customize this behavior, go to the process detail view and click on the name of the status to be changed. This will open the status view page. In this view the detailed status information can be accessed as well as the connected actions and the field permissions. To edit the field permissions click the Edit button on the top of the page. 17

18 In the section Field Permissions of the edit status screen, each field can be configured if it is visible, visible during edit, editable and mandatory by selecting the corresponding checkbox. A field that is defined as visible, will be shown on an object's view page. A field that is defined as editable, will be editable on the object's edit page. A field that is defined as visible during edit, will be visible but not editable on the object's edit page. This is the default behavior for status-relevant fields. A field that is defined as mandatory, will be mandatory on the object's edit page and must be filled before the object changes to the target state. Note: When a new state is created, each field is set as visible and editable per default, so it behaves not different from the standard setup. Due to technical reasons all the fields on an object are configured this way, even if they are not on a page layout. But these fields will not be accessible until they are added to the page layout of the object, regardless what their setting in visuallifecycle is. After you have set up the field permission, you are ready to start working with your new process. Of course you can set up your process in much more detail by leveraging all the other options visuallifecycle comes with. We suggest to take a look at the additional chapters in this document to get to know the application. 18

19 Example Scenario In this handbook, we will use a sample scenario to explain various situations and terms. This might help to explain certain issues more clearly and descriptive. This chapter will only set up the scenario and not contain any visuallifecycle related information. Business Situation ou are running a call center to provide IT support to your company s employees. The call center is supposed to be the single point of contact. Users can contact the call center by phone or . After taking a call or processing an , the call center agent ( agent ) creates a support ticket to track the process of the user s issue. ou are the call center s overall manager and supposed to ensure that service level agreements (SLA) are met, tickets are properly handled, budgets are saved and timelines are kept. Parties Involved This scenario will feature the following parties: Users A user will contact the call center if she faces an issue with her IT equipment. Users might or might not have IT experience. Agents our call center agent team consists of several people that are supposed to be the first line of contact for your users. our agents are divided into two groups: Agents with basic training (or First level agent) and Agents with advanced training (or Second level agent). If a user calls the support hotline, he will reach on of your agents with basic training. Technicians Technicians are highly trained and experienced IT personnel who know your companies software, hardware and environments. The technicians do not work for your department directly but you can contact them if your team is unable to resolve a user s issue. However your department will have to pay for each technician reducing your available budget. Team Leads There is one team lead for each agent team and one technician team lead. The latter one however is not situated in your organization. Salesforce Setup our call center will track support tickets via Salesforce s built-in Case object. The users calling your call center will not necessarily have a record in your Salesforce organization. The technician s department however is also using the same Salesforce organization as you are and each technician has a user record. Basic Workflow The basic workflow in your call center is depicted in Figure 12 below. A user calls or s the support team and reaches an agent with basic training (first level support). If the agent is unable to resolve the issue, she forwards the issue to the work queue of the agents with advanced training. An experienced agent then picks 19

20 up that case and tries to solve it. If he, too is unable to solve the issue, he assigns a technician to help the user. Anyone of those persons involved can close the case if he/she is able to solve the issue. The entire workflow is not used everywhere in some situations it might be simplified (e.g. some stations are removed). Call/ Forward Accepts Assign User Call Center Agent (Basic Training) Work Queue (2 nd Level Support) Call Center Agent (Advanced Tr.) Technician FIGURE 12: BASIC CALL CENTER WORKFLOW 20

21 Component Description Within visuallifecycle there are various terms used to describe objects or tools. This chapter explains every major term to help you better understand how to work with visuallifecycle. Process A process describes an object s lifecycle within Salesforce. An object (such as Case, Opportunity, etc.) moves through a process as it is being processed at various stations. If you think about the Example Scenario described previously, a process represent a Case object from the moment it is created by the first level agent to the moment the issue is resolved and the case is closed. The can be one process per object/record type combination, that is if you have no record types defined for an object (i.e. you use the master type) you can create one process for this object type. If you have two record types defined for one object, you can create two processes for this object one for each record type. Usage ou can create processes by selecting visuallifecycle as your active Salesforce application. Then click the Processes tab and click New. Now enter a name for the process and select the object type you want to create the process for. If you select an object with more than one record type, you have to select the respective type after clicking Continue. The final step is to select the status fields that will comprise each process state. Please refer to the linked chapter to get more information about states, status fields and status values. Note: Status fields cannot be changed after initial process creation! Process Wizard The Process Wizard is one of the major administrative features of visuallifecycle. It is a browser-based, graphical editor to design your process flow in. ou create all your process states and actions within this tool. Once you have created your process in the Process Wizard, your users can use it and meanwhile also leverage the Process Guide. Keep in mind that the Process Wizard is meant for administrators (or process administrators) to model your business processes in Salesforce. These processes can then be lived by your users afterwards. An end-user (such as call center agents, users or technicians) will not have access to this tool. Usage ou can easily create new states. Just click the New State button to add a state. After adding it to the canvas, you can rename it on the right, define its field values (see State/Status, Status Field and Status Value for more details) and mark it as start state, editable and deletable. Click the Save button on the right to finish modifying a state. Start State ou have to mark at least one state as start state for your process. This is necessary so visuallifecycle knows where your process lifecycle starts. Editable 21

22 If you deactivate this checkbox, your users cannot edit any records once they reach this state. They can however invoke actions to move a record on in its process lifecycle but no values can be changed by the users. Deletable If you deactivate this checkbox, your users cannot delete any records once they reach this state. They can however invoke actions to move a record on in its process lifecycle. Note: Actions and states are marked as inactive after their initial creation. ou have to enable them by clicking on them and then click on the gear icon. If you want to modify an existing state, click the respective state and click on the pen icon afterwards. Now you can change its values on the right hand side. Click the Save button when you re done. ou can link states together by adding actions. To add an action, click on the source state. A blue (not connected) circle appears to indicate that you can attach a new action here (see Figure 13). FIGURE 13: NEW ACTION SOURCE Click the circle and it will turn orange. Now move your mouse over the target state. Note that the target states border will also turn orange indicating that you can click it to create the action. After you clicked, a connection has been established and you can rename it on the right hand side. Click the Save button when you re done. Example Figure 14 shows a simple example process in the Process Wizard. As you can see, the process has three states (New Case, Working on Case and Case Closed). Each state is linked with another by an action (depicted by the green arrows). FIGURE 14: EXAMPLE PROCESS IN PROCESS WIZARD In this example, the user will be able to invoke two different action if the process object is in state New Case. The difference between those actions is the state in which the object (in this case a Case object) will be after the invocation (see also Figure 15). 22

23 Process Guide The Process Guide as another major feature of visuallifecycle. It helps the user keep track where in the process she currently is. Each record in Salesforce represents an object in a certain state of a process (assuming there is a visuallifecycle process for the object). The Process Guide provides a graphical representation of the position within the process. FIGURE 15: PROCESS GUIDE WITH CASE In Figure 15, you can see the user created a new Case (for the process depicted in Figure 14). The user is currently looking at the case view page. Right at the top of the page the Process Guide is visible, showing the user that the current record (Case ) is currently in state New Case and it is possible to invoke two different actions: Start Work and Close Case. If you think about the example scenario, Figure 15 might show the screen of a 1 st level agent, after she took the call of a user. She can now start to work on the case (and move it to state Working on Case) indicating that it is currently being processed, or close the case directly (and move it to state Case Closed) to indicate that it might not even have been a valid case. Note: ou can hide certain action from the Process Guide. Please see Action for more details. State/Status, Status Field and Status Value A state (or status) describes a record s current position in a process. It is comprised of one or more status fields and a value associated with it. Each state will be a unique combination of status values for each status field. Status fields are defined when you create a new process; status values will be defined in the Process Wizard for each state. A status field is the name for one specific field of the object that is part of a visuallifecycle state (or status). If an object s field is marked as status field, it will not be editable for the end-user anymore and its values will be managed by visuallifecycle. A state can be comprised of more than one status field. Note: Only picklist fields can be marked as status fields! 23

24 A status value represents the value that is set in the corresponding status field in a certain state. To explain this a little more, consider the example scenario and the process shown in Figure 14. The default Case object has a standard picklist field Status. It has four default values: New, Working, Escalated and Closed. The process shown in Figure 14 uses only that field to determine the state. Table 2 shows the configuration. In each state a different value will be set for this field. State Status Field Status Value New Case Status New Working on Case Status Working Closed Status Closed TABLE 2: PROCESS STATES, FIELDS AND VALUES As you can see, when a record is in state New Case, visuallifecycle will set its field Status to the value New, when it s in state Working on Case, its status is set to Working and so on. That itself seems to be easy enough for a simple process. Now consider a more complex situation in the process referenced above: If one of your users calls in to report an equipment breakdown, she needs a quick solution to the item to get her back to work. Therefore the process is modified to look as shown in Figure 16. FIGURE 16: PROCESS WITH MULTIPLE STATUS FIELDS Here the process was modified to handle high priority support cases. The agent can now either decide to start working on the case, or make it a high priority case and work on that. The reason could be that there are different SLA, budget limitations, etc. for high priority cases. In either way, that process shows how one state can be comprised of multiple status fields. When that process was created, two status fields were selected: Priority and Status. Each of the states shown in the graphic now has a distinctive field value associated with each state. The combination of those fields and values can be found in Table 3 below. State Status Field Status Value New Case Working on Case Status Priority Status Priority New Medium Working Medium 24

25 Priority Work Closed High Priority Case Closed Status High Status Priority Status Priority Working High Closed Medium Closed High TABLE 3: PROCESS STATES, FIELDS AND VALUES FOR MULTIPLE FIELDS PER STATE Field Permission For each state you can set field permissions for each and every field of the object. A field permission is a set of settings for a specific field. For each field permission you can specify whether the respective field should be visible, editable, read-only and/or mandatory in a certain state. Field permissions give you the power to optimize each page in your process helping your users to achieve their goals faster with a lower error rate. ou can use field permissions to reduce the complexity of screens, make them show only information that is really relevant. ou can edit field permissions from the state view page. Visible Whether a field is visible at all. If this checkbox is deactivated for a field, the field will not be displayed. Editable Defines whether a user can modify this field s values. If this is deactivated for a field, the user cannot edit this field. Visible in Edit If this is active, a field is only visible in edit mode, but not editable. This field is mutually exclusive with Editable. Mandatory If this is checked, a field has to be filled out for a record to be saved. Note: Status fields can never be set to be editable or mandatory. To give you an example of what you can do with field permissions, consider the example scenario and the process shown in Figure 16. When a user first contacts your support center and the agent creates the case, she does not need so see all the field that a default Salesforce installation offers. What she needs is some contact information, a reason, origin, subject and description. This can easily be achieved by setting up the field permissions for the state. To do that, open the respective state in the state view and click edit. In the field permission list, set all the checkboxes according to your needs. ou can see an example below in Figure

26 FIGURE 17: STATE EDIT VIEW WITH FIELD PERMISSIONS As you can see, most of the fields are not visible to agent at all (neither in view mode, nor in edit mode). ContactId is set to be visible and editable. This will allow the agent to reference a contact record with the new case object and also see any associated contact on the case view page. CreatedById however is set to be visible only, since it does not provide any information to the agent when she creates a new case only once the case has been created will it provide useful information to other agents (see Figure 18 and Figure 19). 26

27 FIGURE 18: NEW CASE FORM WITH REDUCED FIELDS FIGURE 19: NEW CASE VIEW WITH REDUCED FIELDS 27

28 Action An action describes the transition between an object s states. It can be invoked by the user. In the Process Wizard actions are depicted as arrows connecting two states (see Figure 14). While in visuallifecycle easy an action represents a simple state transition, in visuallifecycle professional an action provides you with much more powerful options to customize, optimize and automate your processes in Salesforce. While an action itself seems a single (or maybe a two-step) step action, it actually consists of several internal steps that you can leverage. Figure 21 shows the order in which the steps are executed. All but the second step (purple background) will be opaque to the user. The second step will show the object s edit screen to the user, if it s missing mandatory data or the screen is set up to be shown anyways. When an object is in state S 1 and the user invokes action A, the first thing to be executed are any field updates set to be run before showing any edit screen. After these updates were made, the edit screen is shown to the user (if mandatory data is missing or edit screen is set to be shown always). After the user finishes updating the data and clicks save, the field updates set to be executed after showing the edit screen are run. After the second set of field updates has been performed, the actual object data is being saved. It is important to understand, that no data (not even from field updates before the edit screen) is being stored in the database before this very point. Everything is only stored temporarily since the user can abort the state transition in the edit screen. Finally any object create tasks are executed. Field Update Before Edit Screen Edit Screen (If set to Show Always or missing mandatory fields) Field Update After Edit Screen Object Create Save Obj. State S 1 Action A State S 2 FIGURE 20: STATE TRANSITION TIMELINE Usage When you navigate to the action view page of any action and click edit, you a have a couple of options (see Figure 21). 28

29 FIGURE 21: ACTION EDIT SCREEN Action Name This is the technical name of the action as shown in the Process Wizard. If might be the same as shown in the Process Guide as well, but there is a chance they differ since the Process Guide displays translations while the Wizard displays technical names. Please refer to chapter Translation for more information on translations. Active If this checkbox is disabled, the action itself cannot be invoked by the user and will neither be displayed in the Process Guide nor have a button to invoke the action. Show in Process Guide If this checkbox is disabled, the action itself can be invoked, but is not shown in the Process Guide. There will be a button underneath the Process Guide for the user to invoke the action. Tooltip Any text you specify here will be displayed as a tooltip when the user hovers her mouse over the respective action button. Show Edit Screen Here you can select when a user should see the edit screen for an object. The default is Only if a mandatory field is not filled, i.e. only if there is a field set up in either action field permissions or regular field permissions to be mandatory and there is currently no value set. ou can use this switch to basically toggle whether your user sees the edit screen at all if she decides to invoke an action and all mandatory fields are already filled. If you select Show always the edit screen is always shown, as soon as a user invokes the action. This might give a user an opportunity to quickly modify values even though there is no mandatory field missing. From State/Target State These select boxes define the source and the destination of the state transition. The values selected here were originally created by the Process Wizard. Use Conditional Action/Use action field permissions 29

30 Please refer to the respective chapters below. Conditional Actions ou can set up an action to be only available to the user, if a certain condition is satisfied. The condition is a formula expression very similar to regular Salesforce formulas. Conditions can be managed in the action view pages. Basically you can use conditions to show or hide actions depending on specific process situations. To give you an idea of what you can do with conditional actions, consider the example scenario and the process shown in Figure 16. Since high priority cases are especially hard on the company department s budget, you only want the agents to be able to declare Breakdown cases as high priority cases, since everything else can be covered using regular resources. To modify an action condition, navigate to the desired action s view page. After clicking the Edit button, you have to check the field Is a conditional Action the form will now reload and show the formula editor. FIGURE 22: ACTION EDIT PAGE WITH CONDITION FORMULA The condition formula as present in Figure 22 is show below. $Reason == 'Breakdown' After you click Save, the formula is validated and the action is saved. With the above condition in place, the Process Guide looks different for the user, depending on the Case Reason field. Figure 23 and Figure 24 below show how the Process Guide differs and how the invocable actions are presented. 30

31 FIGURE 23: PROCESS GUIDE WITH UNFULFILLED CONDITION FIGURE 24: PROCESS GUIDE WITH FULFILLED CONDITION While in case there is no reason for the case specified (highlighted area in figure), the agent has two possible actions she can invoke. In case however, the Reason is specified as Breakdown. Because of the formula above, this leaves her with a third option to invoke. 31

32 Action Field Permission Action field permissions are very similar to regular field permissions. Action field permissions however provide you with a way to set up field permissions for a specific action instead of a state. The major advantage of setting up action field permissions instead of regular ones is that you can set up permissions for fields relevant only for that certain transition. Once the object has reached the state itself you might want to show more fields or let the user edit different fields. To illustrate this feature more clearly, consider the example scenario and the process shown in Figure 16. ou can see that there are two different actions resulting in state Priority Work. The first (Start high Priority Work) just follows the regular workflow; the second (Prioritize) however implies that case s priority was not considered correctly and now the case is being re-prioritized. The field permissions for the state will always be the same, no matter what action is invoked to reach it. That said, you can see that there might be a need to present different fields to the agent, depending on how she navigates her case to the state. Different fields in this scenario could be as listed in Table 4 below. EDITABLE FIELDS FOR START HIGH PRIORIT WORK - Subject - Type - Description - AccountId EDITABLE FIELDS FOR PRIORITIZE - Type - Description TABLE 4: DIFFERENT FIELD PERMISSIONS PER ACTION The way to present the agent with the different set of fields depending on the action invoked, you just have to set the proper action field permissions. To do that, navigate to the action view page of the first action and click edit. Enable the checkbox Use Action Field Permissions the form will reload and the action field permission records will be shown (see Figure 25Error! Reference source not found.) under the formula editor (if the current action is a conditional one). The behavior of each permission option is the same as for regular field permissions. 32

33 FIGURE 25: ACTION FIELD PERMISSION LIST After both actions have been set to use action field permissions and the fields are limited as described in Table 4, visuallifecycle will present a screen as shown in Figure 26 when a user invokes action Prioritize. FIGURE 26: ACTION INVOCATION WITH ACTION FIELD PERMISSIONS As you can see only the two fields that have previously been mentioned are presented to the user. That said, action field permissions provide a great way of fine tuning your Salesforce processes to make them run smoother and help your staff to be more productive. Note: If a field is marked as mandatory in the regular field permission list for a state, you cannot mark it as non-mandatory in any action field permission for an action pointing to that state. 33

34 Field Update In visuallifecycle professional you can define tasks for each action to update specific fields on your record when the action is invoked. This provides you with a way to automate updates to your data. Field updates are performed by evaluating a formula you specified. Each field update can be set to be executed either before or after the user saw her edit mask (if there is any). This switch allows you to represent even complex scenarios. Setting a field update to be executed before showing any edit screen to the user allows you to preset certain values, that the user then can override or use. Setting a field update to be executed after the edit screen on the other hand, can set values that the user should not be able to change and therefore has no need to see in her edit screen. For more information on the state transition invocation timeline, please see Figure 20: State Transition Timeline. Considering the example scenario and the process shown in Figure 16, a good point to implement an automatic update would be for the action Prioritize. As this action is currently set up to re-route a case to High Priority Work (which should only be performed for equipment breakdowns), it would be good to automatically update the field Reason to Breakdown. There is no need to have the user update that field by herself. To set up the field update navigate to the action view page and click Edit. When you scroll to the bottom, you will see a section labelled Field Updates. Click New to create a new field update task. In the upcoming form (see Figure 27) you can specify a name for the action. This name is strictly for organizational purposes. After that you can select when the field update is executed: Either before showing the edit screen to the user or afterwards. In this case the user should not be bothered with the data in this field, so it is set to afterwards. Next you have to set up the field you want to actually update. In this case, the field to update is Case Reason. Last but not least you have to specify the formula that should be evaluated to determine the new value for the field. In this case, the value is always the same, so it is just hardcoded there but you can use much more sophisticated formulas here. After clicking save, the record is stored. If a user now invokes the action Prioritize, the case reason will always be set to Breakdown, without the user s interaction. 34

35 FIGURE 27: NEW FIELD UPDATE FORM Object Create and Object Create Field Similarly to updating fields on an action invocation, you can also create new records of other object types upon an action execution. Objects are created at the end of any state transition. For more information on the execution order see chapter Action and Figure 20: State Transition Timeline. For each action you can create multiple objects. For each object you can set single field values the same way as for the field updates. Each field value is determined by a formula in which you can reference the original record values. If you consider the example scenario and the process shown in Figure 16 again, a good place to use and object create task would be the closing of a case. In this example, we want to create a new Solution record, once a high priority case is closed. The solution then should be in a draft state and contain the subject and description of the case. Another employee could then (in a different process) pick up the draft and update it to make it generically usable. To create a new object create task, please navigate to the action view page for the respective action. The page contains a section Action Object Creates. Click the new button to create a new object create task. A form like the one shown in Figure 28 appears. 35

36 FIGURE 28: NEW OBJECT CREATE TASK WITH FIELD VALUES First you can specify a name for the task. This name is for organizational purposes only. Afterwards to the right, you can select the type of object you want to create. In this case we want to create a new Solution object. Now you can specify each field you want to set. Click the New button next to Action Object Create Fields. A new row appears. The first control provides you with a list of all the fields on the selected object. Pick a value to select a field. Now specify a formula that will be evaluated to generate the actual field content. In the image above there are three different fields set up: Title, Description and Status. The title value will always look like SOLVED: Case Name, where Case Name is the name of the current support case that is being closed. If the case s name would be User cannot log in, the solution s name would be SOLVED: User cannot logged in. For more information formulas, see chapter Formulas. The description value will be exactly the same as the case s description, as all field references in the formula field point to the actual process object (in this case: Case). The status of the solution will be Draft. Since the status field is a picklist and we always want the new solution to be a draft solution and subject to review, it is hardcoded here. Now click the save button to save the object create task. From now on, a new solution will be created once a high priority case is closed by an agent. Process, State and Action View Besides the Process Wizard you have one more way to display process, state and action information. Like for almost every other Salesforce object, there is a view page for the processes, states and actions. Within this document they are referred to as process view page, state view page and action view page. The purpose of these pages is to provide you with all necessary information about each item at once. Since each type of object can hold a lot of additional information that cannot be displayed in the Process Wizard, the view pages are the places to go if you want to see (or edit) more detailed data. 36

37 Each view page also has an edit button providing you with a convenient way to quickly update various setting for each item. ou can reach the view pages by selecting the Visual Lifecycle app in your Salesforce app selector in the upper right and then clicking Processes. Now you see a list of all your processes similar to Figure 29. FIGURE 29: PROCESS LIST PAGE Once you click a process name, you will see the process view page of the respective process. Here you can find all the general information about the process as well as all the associated states (see Figure 30 below). FIGURE 30: PROCESS VIEW PAGE ou can go to the state view page by clicking any of the state s names. The state view page again holds all information on that specific state as well as all actions originating from this state (i.e. having this state as their source state), field permissions, translations and picklist filters (see Figure 31 below). 37

38 FIGURE 31: STATE VIEW PAGE (PARTIAL) The action view page can be reached by clicking the respective action originating from the previously selected state. It contains information about the action, action field permissions (if active for the action), field updates, object create tasks and action translations (see Figure 32 below). 38

39 FIGURE 32: ACTION VIEW PAGE Translation Visuallifecycle allows you to easily translate state and action labels. This provides you with a simple way to set-up your process for a multi-lingual environment. Everything you change here will be reflected in the Process Guide that is you have to change your translations as well, if you rename a state or action in the Process Wizard (the Process Wizard displays internal, technical names). When you first create a state or an action in the Process Wizard, its translation will be automatically generated from the name you enter there. However subsequent modifications to that name will not be reflected in the translations. At the bottom of the state view page as well as the action view page, you can find a section Translations and Action Translations. Just click the new state translation (or new action translation respectively) button and a new translation screen shows up. Here you can select a language you want to translate to and specify a translation. Click save to save the translation. ou can currently translate your action or state name into one of these languages: Chinese (Simplified), Chinese (Traditional), Danish, Dutch, English, Finnish, French, German, Italian, Japanese, Korean, Portuguese (Brazil), Russian, Spanish, Swedish and Thai. 39

40 Note: Whatever you specify here will be shown to the user in the Process Guide, if she operates her environment in the respective language! The administration interface of visuallifecycle as well as the messages generated for the current user support English and German. Picklist Filter By setting up picklist filters you can define the possible available values for each picklist in each state. This functionality helps you to reduce your user s available value choices to the ones they actually need, thus increasing your data integrity. ou can set up picklist filters on the state view page for each state. Below the field permission list, there is a section State Picklist Filters. By clicking the new button, you can create a new filter for that state. The call center agents in the example scenario are supposed to select a case origin during the case creation. Since the company does not provide a web form to submit a case, the only valid options are and phone. In Figure 33 you can see an example of a new picklist filter. In this case the set of available options for the user when she creates a new case is limited to only and phone, thus excluding web. FIGURE 33: NEW PICKLIST FILTER FORM When an agent now tries to create a new case, she will only be able to select either or phone but not web, since the picklist filter is active for that state. Note: Keep in mind that picklist filters apply to specific states only! If your objects changes its state, the filter will not apply anymore and your users will be able to select all possible values again. Consider setting the field to read-only using field permissions or setting up more filters for all states necessary. 40

41 Working with a Process Since visuallifecycle looks and behaves very similar to Salesforce your user will not need much of an introduction to get started. Once your process has been set up and configured properly it is available to your users. To give you an idea how a visuallifecycle enabled process looks like to your users, the following sections will work through the process shown in Figure 16 that is based on the example scenario. The initial call One of your agents (Amanda) receives a phone call from one of your users (Uma Smith) and creates a new support case. Note: If the object has more than one record type or more than one start state the user selects these values from a drop down list. After choosing to create a new case, the agent will see the edit screen asking her to input the relevant data. As you can see in Figure 34 some fields are not editable by the user. Among others the status and priority picklist. As these two fields are status fields the user must not be able to manually change these values. The other fields missing from a default Salesforce case edit screen are removed using visuallifecycle s field permissions. The intention is to provide the agent only with the fields she actually needs in that process step. FIGURE 34: NEW CASE OBJECT WITH VISUALLIFECCLE PROCESS Case has been created After the agent clicks save in the form shown in Figure 34 above, she will see the new case in a detailed screen (see Figure 35 below). This screen will also contain the Process Guide. The Process Guide enables to figure out exactly what the current case s state is and what options she has. It will prove to be extremely helpful to the agent once she moves a case further through its lifecycle. 41

42 FIGURE 35: CASE IN NEW STATE As you can see the screen above shows all the information entered in the previous screen (see Figure 34) plus a few other additional values. The visibility of fields in this screen, as well as the edit screen before, can be configured using field permissions. As you can see, all the possible actions available to the agent are shown to her as regular Salesforce buttons next to the usual edit button, the user is used to see with other objects. ou might wonder why the default delete button is not visible. The reason for that is that the New Case state has been marked as editable but not deletable in the Process Wizard. Another agent starts to work on the issue After your agent finished the initial call with Uma, she continues to take calls from other user. Another of your agents (Adam) picks up the case and starts investigating the issue. He now marks the support case as under work by clicking Start Work. The screen changes and the Process Guide shows a different place in the process (see Figure 36). 42

43 FIGURE 36: CASE IN WORKING STATE As you can see in the screen above, the case originally created by Amanda is now in state Working on Case and associated to Adam. Adam now performs various tasks, e.g. trying to reproduce the issue. He can click the edit button to update the case s data. This will provide him with a slightly different form (see below) than the one shown in Figure

44 FIGURE 37: EDITING A CASE IN WORKING STATE Adam can now also provide an account name to assign the case to, select the type of support case (e.g. mechanical, electrical, etc.) and update the subject and description. After he clicks the save button, his changes are stored and displayed (see Figure 38 below). 44

45 FIGURE 38: UPDATED CASE IN WORKING STATE IT solves the performance issue After IT management has resolved the incident that impacted the file share s performance and confirming the situation with Uma, Adam can close the case. He does this by clicking the Close Case button. Since the process was set up to use action field permissions and always show the edit screen during this state transition, Adam is presented with the edit screen so he can update the case with final comments regarding its solution (see Figure 39 below). 45

46 FIGURE 39: EDIT SCREEN DURING ACTION INVOCATION Case is closed After Adam has finished updating the case s information he is presented with the detail view again (see Figure 40 below). Here you can see that the case is closed and no further action can be performed. Additionally there is no edit or delete button, since the Closed Case state has been marked as non-editable and nondeletable in the Process Wizard. 46