Download - Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Transcript
Page 1: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Livelink™: Workflow and Best Practices Application Note

Livelink™: ECM Workflow and Best Practices

Page 1 of 21

Title:

Livelink ECM Workflows and Best Practices

Abstract: Application Note dealing with Livelink Workflows and best practices for workflow design, management and use.

Release Date: Winter 2006 (Version 1.1)

Livelink Version: 9.5, 9.6, 9.7

Audience: • Administrators • WF Map Designers • FAQs

This application note was written in an effort to enhance product information that may not be covered in documentation to date and to expand on information that is presently provided either in Livelink Training Courses or Customer Support materials.

Overview

The following document is an attempt to compile a number of best practices, recommendations and suggestions for the designing, editing and managing of Livelink 9.x workflows. While most of these best practices applies to most Livelink 9.x systems, this documentation has been written against versions 9.5 SP1, 9.6 and 9.7. Where behavior of Livelink is known to differ between versions, every effort will be made to identify the differences. Where necessary, specific areas of the best practices will be covered as follows: • Understand Process • WF Map Design • Map Editor • Management • Attachments • Permissions • Best Practices • Troubleshooting • Dates and Times • Users and Groups • Replacement Tags • Loopbacks • Sub Workflows • Export • Testing • WF & LiveReports • Process Automation • Item Handler Step

Application

The following document will touch on some topics and subject matter that is currently covered in Livelink Training courses, including the following: • 9x-120: Workflow Design I • 9x-220: Workflow Design II • 9x-221: Workflow Design III (if planning to use Item Handler step) • 9x-223: Forms (if planning to use Forms) • 9x-224: e-Forms (if planning to use e-Forms) Some or all of these courses should be considered as required training for individuals who plan on designing and maintaining Livelink Workflow Maps. For those individuals who plan to merely initiate, interact with WF instances and packages or manage the maps, this basic information is covered in the 9x-101 Knowledge Fundamentals and the 9x-201 System Administration courses.

Background(*)

Page 2: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 2 of 21

Introduction The Livelink Workflow is a powerful mechanism for automating and monitoring business processes. Livelink Workflows provide a set of features and options that allows an infinite number of unique workflows to be developed. Understanding and Illustrating the Current Business Process Begin small. Start with a small, simple process that is used by a limited number of people and continue to work on it until it works perfectly. Next, select a medium yet basic process that is used by a few more people and on a more regular basis and .perfect this workflow. Finally, select a larger, more complex process. By the time this larger, more complex process is automated, both elements and the process of Livelink Workflows and its users should be well established. The first step at arriving at any solution is to understand the problem. This aspect should be considered the most important step of the process; without adequate clarity of the business needs, it is unlikely that the solution will be on target. To understand the business process it is necessary to break it down into recognizable individual parts that can ultimately be mapped to features within the software. Once the participants (users), packages (materials) and path (route) have been identified for a given business process, this information can then be applied to the design of the Workflow Map and related processes. Identify the business Participants. Participants or if you prefer, users, refers to the individuals or entities who perform steps or make decisions as part of the business process. For example, these could be editors, reviewers, decision makers and managers. Participants can be specifically named individuals, groups or defined as a functional role. Participants are not strictly performers in the process, but include persons who manage or monitor the process as well. Participants can also be other systems that you wish to send data to or receive data from, such as an SAP system. Packages may consist of supporting or related materials that are part of the business process. The term package refers to the data or materials that are routed, reviewed and stored as part of the business process. Examples of packages include documents, metadata elements, electronic forms and comments. Path or route refers to the routes that the packages take in the process. Paths in processes are dynamic in nature and are determined via data values or decisions made by workflow participants. Diagramming, is the next logical step in documenting the WF process, involves creating a visual representation of the process using suitable media such as whiteboard or in an electronic format that lends itself to editing like Microsoft ® Visio. Where possible each view and vantage point needs to be considered ranging from the end user performing the work, to the decision makers to the people who will be managing the WF and business process. If the resulting WF and related processes is not suitable, then people will not buy into it nor use it. From the information gathered so far, begin determining what functionality you will need to complete the work at hand. Can your project be completed using the tools immediately at your disposal or is additional functionality or modules required? For example: HTML or Web Forms, e-Sign for digital signatures, e-Forms to make use of advanced Form capabilities XML Workflow Interchange (XML WFIC) to transfer XML data to other systems. At this point it may be helpful to tabulate or map out what steps and WF items would be helpful in meeting various business requirements. Where additional modules are required, that too should be noted.

Settings & Discussion

Best Practices Abridged List

• Start small • Understand the Problem • Identify Participants • Identify Packages • Identify Path • Diagram the Process • No ad-hoc WF Maps • Use groups, not one user • Consider WF Proxy • Consider data

Understanding

Understanding the problem to be solved is crucial!

Livelink workflow is best used for structuring, standardizing, and automating processes that are repeatable and critical to the business. The biggest value is realized when using Livelink to automate cross-functional processes where traditional manual processes are slow, error-prone, lack visibility or traceability, and suffer the inefficiencies of departmental communication. Livelink will excel at repeatable, structured processes. Where a process could be considered a one-off, then it may be necessary to examine other alternatives, however, you could use Livelink to create one-off-workflows.

Page 3: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 3 of 21

First Pass at Mapping out the Process to Livelink Steps – Story Boarding The following guidelines should be used when developing flow charts documenting the WF process: • Processes should be mapped left to right and top to bottom • Each flow chart item or shape should contain one discrete event • For complex processes, a main process should be diagrammed with sub-processes in separate diagrams • Compartmentalize your processes where possible, for example there may be separate stages of a business process where documents are created, marked up, approved and then released or published. Designing the Solution Designing the solution involves mapping the process that you have outlined above into the specifics of the Livelink Workflow to match each of the aspects of the business process as outlined earlier to standard features of Livelink Workflow. Many of the process requirements that have been identified can be directly mapped to specific workflow features, such as participants to workflow performer types. Other workflow features that don’t have direct mappings can be used to enhance the process that is already in place, such as instructions on each step assignment to guide the user. Participants to Performers Mapping of process participants to Livelink Workflow performers is a straightforward process. First, it should be determined if the Initiator step is appropriate for the design. In situations where different users initiate the workflow and the process involves review or approval of that user’s submissions, the Initiator step should be used. WF Steps that have a group of participants can simply be mapped to an existing Livelink group or a new group can be defined. When the customer has identified individual Participants for certain tasks in the process, some questions need to be asked. If the process is time-sensitive, it is not a good idea to have a single user indicated as a step performer, even if that individual will be performing the step 99% of the time. It creates a problem should the user be unexpectedly absent (as no one else can perform the task). In this situation, it is a good practice to create a Group to perform the step. Include in the Group the person who normally performs the step and some additional personnel, such that one of them will be able to perform the task when the regular step performer is unavailable. This way the process will not stall due to one individual’s absence. An alternative to this approach is to make use of the WF Proxy (more on this later). Packages to Data Elements There are three basic types of data that may become part of the WF packages that flow through their business process. Correctly determining the type of data will help to determine how it should be modeled in the workflow process. Some of the data used in the WF may help determine the paths that the work process takes (accept/reject disposition or attribute data). Every data element that is added to a workflow is saved in the database including: dispositions, attributes and comments. These data elements can be used to report on decisions made by participants as well as assisting in determining which path the workflow will take. An example of this kind of data is a disposition. Metadata is data about the documents, forms or other Livelink objects that are being routed. Metadata can assist in searching and reporting. Examples of metadata are workflow attributes and object categories and attributes. Workflow attributes are process-centric and useful in later reporting on the process itself. Categories and attributes are object-centric and follow the objects within or outside of the workflow process. Attachment data can also be an important and integral aspect of many workflows. The workflow package (Attachments Folder) and associated functionality is available to assist customers in standardizing processes, whether it is document – centric or data – centric.

Settings & Discussion

Cautionary Note on Groups and Group Leaders

One important ‘feature’ to consider during the assigning of groups to WF steps deals with sub groups and group leadership. As you know, you can create a sub group and assign it as a Group Leader. The benefit of doing this will allow users in the sub group to manage the user base in that group. One potential consequence that may be unanticipated is that each of theses sub group users will receive a WF assignment when the step becomes available with a Member Accept Group option. At the present time, there is no way to exclude the sub group membership in this example.

Page 4: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 4 of 21

Reporting and Notification Identifying where reporting and/or notification is required as part of the workflow process is an important aspect of workflow design in that it is the monitoring mechanism for the process. Reporting and notification options include standard shipping Live Reports, custom Live Reports, Web Reports, Notification and Process Step email notifications. Although you could consider using the Process Step to send email messages with then intent of notifying users that a Workflow step has arrived and requires their attention, the email capabilities of the Process Step are rudimentary and do not have the same dynamic functionality offered by Livelink Notifications to alert users when step assignments arrive in their in-box and also email their notification reports. Beginning with the Embark modular upgrade for Livelink 9.5 SP1 and then subsequently included in Livelink 9.7, WF map Designers have the ability to send WF steps directly to users email addresses, based on the email address stored in their Livelink profile or login. Some Useful Facts and Best Practices to Consider During Map Design • Documentation can use the term WF Task and WF Step interchangeably • The audit trail in the WF package is separate and independent from the system audit trail •Attributes cannot be easily copied from one WF map into another; consider creating a master map or a kind of map template with attributes that can be copied • When Exporting a WF Map, attachments like forms and documents are not included. Use either Project Templates or XML Export to capture WF forms, templates and attachments to move content from one system to another • When moving from one web page to another during map design, be sure to save your work using the Add to Workflow Definition button ( ), otherwise your changes could be lost • Save your work often. When PAINTING a map, workflow changes are saved in memory on the server and written to a cache file. The Java Applet reflects the most recent version of the cache file. Only when you save the map does the definition get saved to the database. Set the version limits on your workflow maps. Since we trust that you are saving often, you will quickly create many versions of the map, so we recommend that you let Livelink automatically purge old versions as you create new ones. • Use the Edit Performers functionality on the WF Map to ensure that all steps have an assignee • Use the Verify Map functionality to test the WF Map has no other reported errors • Consider using HTML tags like numbered list to make steps instruction sets more readable and use WF replacement tags to provide dynamic step naming • When picking assignees or users, use the ‘easter island head’( ) instead of trying to key in assignee

Settings & Discussion

WF Agent

By default, the Workflow Agent is configured to perform background tasks every 10 minutes, but the Livelink Administrator can configure its schedule. Workflow Managers can see that a workflow agent is processing a task in the workflow status view. A step currently being processed by the Workflow Agent will have a red border. On the audit trail for the step, a record will read: Processing on Step "Step Name" was started by the Workflow Agent. When the workflow agent has completed its work, the next step in the workflow becomes ready (if it is a user step, it is not processed until the user works on it).

Page 5: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 5 of 21

• For users to imitate a WF map, See and See Contents permission is required. • For users to initiate a WF or where Forms are present in the WF, a minimum of "See" and "See Contents" are required on the workflow map and on the form templates. • A minimum "See" and "See Contents" are required on the workflow map and on the Form Templates and at least one step to be able to initiate it. • Consider using Shortcuts / Aliases to WF Maps so people do not have to navigate to the map. • Assign steps to Groups as often as possible. It will save time and give you flexibility with your performers. If you wish to change performers, you can change the Group membership, not the Workflow. • Disable versioning on WF attributes unless you have a specific requirement to track changes made to attribute values. By keeping versioning enabled (the default setting), you grow your database table unnecessarily. • If your process has many evaluate steps and loop backs, try to paint the map so that these evaluations and loop backs are in blocks, and make the blocks sub-workflows. This will make initiation much faster and finishing tasks that do loop backs will also be more efficient for Livelink to process (more on loopbacks later). • The mantra concerning loopbacks should be chanted once a day during map design: “I shall remember that loopbacks can be nested, but they cannot intersect. • Try to ensure that the first step(s) in the workflow are NOT evaluation steps (as these will make initiation take longer). • The business need should determine when to use recalculate due-dates. If performance becomes an issue, then an Architecture Assessment should be performed to profile the Livelink system and recommend a suitable architecture. • There is a potential performance impact if WF Map Designers use multiple nested evaluate steps as opposed to simplifying the evaluations, however, business needs will dictate how the WF Map must be drawn.

Note: Each time a step is processed, Livelink must load the entire map definition into memory to evaluate the conditions; the more steps on the map, the longer it will take for Livelink to process. Creating fewer evaluate steps reduces the number of steps on the map and allows Livelink to evaluate the same branching logic all at once.

• When using the workflow agent to finish a step, control is returned immediately to the end user and the browser refreshes. The workflow will move forward in the background by the workflow agent Browser Settings • Browser Settings, including visit page every time • Browser and computer workstation should use a supported java (JRE) version •While editing or painting Maps (also when Suspend and Modify Map) do not use browser back button

Settings & Discussion

WF Map Rules to Live and Die By (Abridged List

• Browser Settings • Save Often • Do not use Back Button • Test and Retest !

Painting in Parallel Do not paint automated steps in parallel. It is recommended to serialize these automated steps. The issue is executing event scripts in parallel, not process steps (it just happens that most event scripts are executed on a process step). The real issue is database contention. If you have automatic steps that do not perform database updates, then there are no issues with executing in parallel.

Page 6: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 6 of 21

Workflow Map Naming Convention(s) Workflow maps have two distinct names that must be considered. The first name is that displayed in the Livelink system. The second name is the workflow map (step) internal names. Step names are important for both the Designer and the end user. Step names are visible in the Workflow Status page during map status review, and (more importantly) displayed in the user's assignment list from Personal Assignments. Are there any strict conventions? No. It will vary from one business organization to another. The more details that are provided in the name, the more meaning it will offer to users of the system. Defining the Process • Create needed WF performer and manager groups • Set general options for entire workflow • Set all workflow management options •Assign groups or users to all steps via the ‘Edit Map Performers’ function •Select the appropriate group completion option for group steps • Define all workflow attributes • Edit all WF Step names to be unique and descriptive. • Define all dispositions. • Create all Step connections and routings (parallel, rendezvous, loopback) • Attach all attachments and set permissions • Set all task durations as desired • Set step options for initiation, delegation • Hide any unused options (attachments, comments, attributes). • Create and paste HTML instructions for all tasks. • Set all process step email notification options.

Naming Groups: The role-based performer groups should be named clearly, based on the roles that the participants will perform. Prefacing the name with ‘WF-‘ is a recommended or common practice, as it makes future maintenance of the groups easier by clearly indicating that the groups are related to workflows processes.

WF Step Instructions: Providing clear and concise instructions for each workflow step is the key to making sure that users understand the actions they need to perform to complete a step. Using the feature that allows the instructions to be written in HTML and pasted into the instruction area makes them more readable and is a recommended practice and highly encouraged. Using the workflow replacement tags is also a great way to personalize the instructions to the performer. URL links to Livelink documents or other pages in the workflow screen can also be added as part of the HTML based instructions to save the users clicks.

Advanced User Features: More is not always better. Use the ‘Send for Review’ and ‘Delegate’ options sparingly when first implementing a workflow. These features, while powerful can make it more difficult for the end user to understand what they need to do. These types of features are best deployed after a workflow has been in use for a while, when a need becomes obvious, or when users might benefit from the extra flexibility.

Settings & Discussion

Only a Name

Prior to Livelink version 9.5, marking up a WF map was done by choosing 'Paint'. Beginning with version 9.5, ‘Paint’ was replaced by the command ‘Edit’. For those less familiar with the Suspend and Modify Map functionality.

The interface uses the command ‘Modify’ when it really means ‘Save the Modified Map’ both in the Quick Link and menu drop down sections.

When you are ready to SAVE your modified map, choose MODIFY on the menu.

Page 7: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 7 of 21

Dates and Times All of the utilized dates and times are based on the system hosting the Livelink database and its time clock. Each step in the workflow can have a specified duration, in days or hours. If that duration is exceeded, the workflow status becomes Step Late You can set specific due dates in milestones. If the date specified in the milestone has passed by the time the workflow reaches the milestone, then the workflow status becomes Milestone Late. Livelink can calculate an overall workflow due date programmatically when a workflow is initiated from the map. When the duration of all the steps has been exceeded, then the status will change from Step Late to Workflow Late. The Start Date field in a User Step specifies the earliest date on which the step should appear in the assignee’s My Assignments page. This is useful if, for example, you are coordinating an assignment with the availability of another resource such as a laboratory. Options for these due dates include: • Skip Weekends: This option is useful if you are using step durations and you do not want to include weekends. The option is found in the General Settings page of the workflow. • Recalculate due dates: This option is useful when you want to readjust the due date for remaining steps when the current step is completed. The workflow tables are updated with the new due dates for future steps. Using the “Recalculate due dates” feature can be a costly function in terms of performance. This function will update all due dates in the workflow table to reflect the new due dates. This calculation is typically done once upon initiation. By recalculating again, it does slow down the workflow performance. Important for designers: a Milestone must follow an evaluation step in order to be properly evaluated by it. If you select the option of Calculate Target Date, the due date of the milestone will match the most previous User Step. A date specified via Enter Target Date will not be so dynamic; most likely, the workflow map will have to be updated before initiation Milestones can be useful markers in a workflow - when they are passed events are added to the workflow's audit trail. You can also use milestone due dates to help drive the workflow, defining a specific milestone due date or letting Livelink calculate the due date. If the due date for the milestone should be the same as the due date of the prior User Step, leave the Calculate Target Date option selected. The milestone due date will be filled in with the appropriate date during the workflow instance. In order for an evaluation step to incorporate a milestone deadline, the milestone must be located immediately following the evaluation step, along the false or true path.

Settings & Discussion

Start When?

The Start Date feature is rarely, if ever, used because there is no way to dynamically set the start date. Instead, use the XML Workflow Extensions Wait step to pause the workflow a specified amount of time. The specified amount can be a workflow attribute, or other data source (like a file on the Livelink server).

Due Dates

Something to note about workflow due dates: Livelink will ONLY provide a workflow due date if every step on the workflow map (including sub-workflow steps) has a duration defined. No duration=no WF due date. IMPORTANT: using add-on modules that add new workflow step types (like XML WF Extensions) may prevent a workflow due date from being calculated, even if you have every step defined with a duration.

Page 8: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 8 of 21

User and Group Options If a task has been assigned to a group (one level or full level expand), the task will not proceed to the next step until all members have completed it. If someone is absent, and has not set a workflow proxy, then the work will not proceed until that person returns and completes the task. When assigning work to a group, there are four options to choose from to determine who has to complete the task: • Member accept: When one member accepts the work, it is removed from the Assignments page of all other group members. • One level expand: Each member of the group must complete the task. If the group has sub-groups, one member of each sub-group must also complete the task. • Full level expand: Each member of the group and all members of all subgroups must complete the work. • Member Accept [Maintain]: Use this option if the task is part of a loopback design. When a task is assigned to a group, the same user that processed the task the first time will automatically receive the work the second and subsequent times. Advanced User and Group Options Please note that the WF initiator assigns users to roles at initiation. All defined roles are presented, whether or not you’ve assigned them to any steps. When assigning any WF step to a combination of users AND groups, then any selected group will adhere to the “group options” that have been selected for the step. The Workflow Design II course covers this particular Advanced User ‘Role’ option in much greater detail, however, the following single table extracted from that course may help to illustrate some of the properties of the Role – based WF. Experimentation and testing with the Role functionality should be part of the map design and testing process.

Question: For a Role: For a User Attribute:

Who Chooses the Group or User?

The Initiator. Anyone in the workflow who has Editable access to the user attribute.

When is the User or Group Chosen?

At Initiation. The initiator must populate all the roles before the workflow can be initiated

At any point in the workflow, anyone who has Editable access to the user attribute can choose a user or group.

Can the Specified User or Group be Modified?

No. Once the workflow has been initiated, a role cannot be reassigned.

Yes. Anyone who has Editable access to the user attribute can change the user or group.

Settings & Discussion

Authenticate and DS

Directory Services provides two types of functionality, namely: synchronization & authentication. Synchronization has no impact on Livelink WF authenticate because the user passwords are still managed by Livelink locally (behaves just like DS is not installed). Using DS Authentication forces Livelink WF authentication to pass the credentials to the authorizing application (LDAP or Active Directory) and will evaluate the response in the HTTP header REMOTE_USER (this is the same way Livelink works when logging in with authentication enabled by providing your Domain Password.

Users and Groups

Assigning steps to groups with only one user. While a great idea to allow administrators to manage workflow participants outside of workflow, there is a negative side-effect that the user may receive two notifications when using the Notification mechanism of "A workflow step has arrived in my Personal Assignments". The reason is you get one notification for the user, another notification for the group. This is a known bug and does not have an ETA for a resolution.

Page 9: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 9 of 21

Replacement Tags A tabulated list of supported Livelink WF Replacement Tags is provided below. Workflow map designers should consult the on-line help (support\help\_en_US\webwfp\wf_use_tags_bg.html) to see where the Replacement tags are or are not supported within the map design interface. Beginning with Livelink 9.5, there is support for the use of <WorkID /> in workflow title and the Process Automation email fields. <InitiatorMail /> should work in any field that allows replacement tags. The <SubWorkID /> tag is only supported and accurate in Process Automation Step Email fields; for all other steps and fields, it will put something in other fields, but it will probably not be what is expected, and as such is not supported Additionally, WF Map Designers may wish to improve the appearance and readability of any text in a work package, such as instructions, comments or initiation message. Typical HTML tags can be used. (e.g., Bold: <b> </b>; Emphasis (italics): <em> </em>; Line break: <br> </br>; Ordered list: <ol> </ol>; Bulleted list: <ul> </ul>. Priority Values stored in the db are 0 for high, 50 for medium and 100 for low. Q: Is the alteration of a priority committed as a record in the audit table? A: No. Q: What permission does a manager need to have to alter the priority? A: Change Data

Settings & Discussion

When mapping, only the type must match, not the name of the attributes. You can’t map category sets to workflow attributes, as sets are not possible in Workflow attributes. The valid values, in a popup-type attribute, are case-sensitive. In order for these values to pass between workflows and categories, they must be identical. This means “approved” is not the same as “Approved”

Supported Livelink Replacement Tags

Replacement Tag Result

<Initiator /> The formatted name of the initiator. <InitiatorMail /> The e-mail address of the initiator (via KUAF profile). <InitiatedDate /> The date the workflow was initiated. <WorkflowTitle /> The name of the top level workflow. <SubWorkTitle /> The name of the subworkflow. <ParentTitle /> The name of the workflow that started this subworkflow <SubInitiatedDate /> The date the subworkflow was initiated. <WorkID /> The work_workid in the Wwork table. <SubWorkID /> The subwork_subworkid in the WsubWork table. <DataType_1_3_WorkflowAttributeName /> Returns the value of the specified workflow attribute. <DataType_1_4_FormID_FormAttributeName /> Returns the value of the specified workflow form attribute.

What do the numbers mean in DataType_1_3_ and DataType_1_4_FormID? The numbers '3' and '4' refer to the index value of the corresponding package of a workflow. The 3 refers to the attributes package, the 4 the forms package. The remaining packages Attachments and Comments are index values 1 and 2 respectively. For DataType_1_4_FormID, the FormID is the index value of a form associated with the workflow. This index value is assigned when you add a form to the workflow and increments by one for each new form added. You can see which index the form has by going to Map > Forms and hovering the mouse pointer over the Name of the form template. In the status bar of the browser you will see the URL to open the form; one of the parameters in the URL is Index=number. This number will be the index value to use in the DataType_1_4_FormID tag.

Page 10: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 10 of 21

More on Workflow Map Permissions The manager of a workflow monitors the workflow instance (an executing copy of a workflow map) to ensure that it proceeds properly; the manager can stop, suspend, or modify it when needed, with the appropriate permissions. By default, the initiator of the workflow is its master manager, but you want to assign management of the workflow to another user or group. You change the workflow's manager and set permissions for the initiator and manager or managers of the workflow on the Edit Management Permissions page. The master manager of the workflow has full management permissions for the workflow. These permissions are: See Details, Suspend, Stop, Delete, Archive, Change Permissions, Change Data, and Change Route. You may, for example, want the initiator to be able to edit all aspects of the workflow instance except the path that the work process follows. In that case, you would give the initiator all permissions except Change Route. In addition to the Master Manager, you can set as many additional managers as you wish. These managers can have any combination of management permissions. You can set a group as a workflow manager, in addition to a single user. Management permissions appear nested on the Edit Management Permissions page, showing their dependencies. You cannot assign a nested permission without assigning the permission upon which it depends. More on Attachment Permissions Map Designers need to review Attachment Permissions. The map design needs to ensure that the permissions assigned to workflow attachments meet your security requirements and that enough permissions have been granted for users to perform the required actions at each step. There are typically three ‘flavors’ of attachments: desktop, copy from Livelink and shortcut or alias. It is important to note that the default permissions on the attachment ‘folder’ with respect to public access is Full Control. This means all WF step users can do anything to the attachments, including deleting it.

Settings & Discussion

Management Permissions

Although the intent of Management Permissions is to allow those who should have management rights over an active workflow, assigning groups with See Details permissions is a great way to allow users who are not participants of the workflow access to view status of the executing process. Users with management permissions to a workflow will have the ability to navigate to the Workflow Status page of that workflow directly from their Personal Assignments page by clicking on the workflow title (the far right column of the assignment).

Attachment Permissions

Since public access has full control on the workflow attachments package, ALL USERS IN LIVELINK who have Public Access enabled will be able to view the workflow attachments. This includes users who are not participants of the workflow and do not have management permissions. Users gain access to workflow attachments through search. In Livelink 9.5 the attachments package was moved to a new volume. This should eliminate the ability for users to retrieve attachments documents through search.

Page 11: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 11 of 21

Troubleshooting Workflow Paths The evaluate step offers many options. Here are some general pointers to consider when creating complex expressions: Every outcome defined in the Expression Builder must have a path to follow. In expressions that have many potential outcomes, you must ensure that the Evaluate step will address all of the possible outcomes. Create a truth table or matrix of all the possible values and their outcomes. Your evaluate step should have a path for each of these values. True tables are discussed in the Workflow Training course. Don’t forget to include a false path if it’s possible that none of the expressions will have a true outcome. The false path can be used as the option to follow if no statements evaluate to true. This could be the last case in your scenario or it can catch all – other workflow expressions that have no valid route. When you include a false path, the workflow will not hang indefinitely or complete prematurely and it will always have a path to follow. Use the evaluate and User Step expression builders at the appropriate time. If all of the steps that branch from the evaluate step contain the same task, but will be sent to different user(s), then the User Step expression builder is a better choice. The more complicated the workflow routing, the more testing needed to make sure no routes are left “un-routed”. The Verify Map Definition function will not check to make sure that all outcomes have been considered in the evaluate step. Unlike the evaluation step expression builder, the User Step stops evaluating when it reaches the first “true” path. Programmers call this an “if / else” structure. This is an important distinction that you should keep in mind.

Common request: "On the fly, I want to be able to specify a range of individuals who would perform the next step. Conceptually this would work exactly the same as if these people were all members of a Livelink Group, where the step is assigned to all group members. However, the group would not exist until someone earlier in the workflow process filled out a set of attributes.” To do this, add a multi-value user attribute and have the step that is supposed to pick the performers add as many users as needed.

Settings & Discussion

Best Practices Abridged List

• Every Outcome with Path • Include False Path • Use right Steps

Page 12: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 12 of 21

Loopbacks Many business processes contain steps or procedures that need to be repeated. Loopbacks are workflow paths that repeat a section, and they appear on the painter (or map) as blue lines. Loopbacks may originate or terminate at any kind of step except a start step, and you may nest loopbacks as many levels as you like. The rules for Livelink loopbacks are straightforward, and you will get an error message if your loopback is not allowed. It may be of interest to note that painting loopbacks became more restrictive in Workflow Maps between Workflow Module version 3.x and version 4.x. Further loopback painting restrictions were implemented beginning with Livelink version 9.5 Service Pack 1 and continue through to the current version of product. Here is a list of general rules: • A loopback set, which is all the steps involved in the loopback, may never include a start step. • A step may produce only one loopback. • A step can be the termination point of multiple loopbacks. • Paint your outer-most loopbacks first, then your inside ones.

• This can get a little confusing because of the way a map gets painted. In fact, Livelink will sometimes interpret what is in fact an inner loop as an outer loop. • When you run into a situation where the painter gives you an error when you know it is a valid loopback, change the order in which you paint the loopbacks (delete the link and recreate the loopback).

Loopbacks and Evaluation steps: if there is only one path emanating from the evaluation step, and it is the loopback, then the loopback is true. If there are two paths, then the loopback is always the opposite of the defined path (meaning, if the link is green, or true, then the loopback will be false). The following set of illustrations may help demonstrate some of these fundamental loopback rules:

Settings & Discussion

Common Question

Question: Why can’t you loop back to the start step? Answer: Because the start step happens before the workflow is initiated.

Page 13: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 13 of 21

The loopbacks that were created in example “A” are valid; loops are nested properly. The loopback created in example “B” is invalid because the inner and outer loops cross over one another. Examples “C” and “D’ are variations of the invalid loopbacks like we seen in example “B”. Another illustration, below, shows the consequences of a loopback where multiple steps may become ready at the same time. This is particularly problematic for Livelink version 9.2 and earlier. During the design of the map, there will be no warnings or error messages that the design is flawed. At run time, assuming that conditions are right to allow two or more steps to be due at the same time, then conflicts could arise causing steps to hang or disappear. In this specific example, the path going from “B” back through “A” and the evaluation step will catch up to the path “C”, the workflow steps will disappear from the assignments page. If, however, “B” path does not catch up to the “C” path before the “C” path moves on, the workflow assignments will not be lost.

Settings & Discussion

Page 14: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 14 of 21

Sub workflow The sub-workflow step initiates another workflow, but it will skip the start step. It’s important to remember this when designing a sub-workflow. You can create a recursive sub-workflow - a workflow that calls itself. There may be workflows that you wish to have started over again for processing or auditing reasons. You can use sub-workflow steps to: • Segment a complex workflow into smaller, more editable pieces. • Help simplify the workflow’s design so you can better understand its flow and business processes. • Embed standard procedures as a subset of a larger procedure. • Help individual departments retain autonomy over their processes. Splitting a workflow into sub-workflows can also help the performance of your workflow, especially at initiation, since the workflow doesn’t have to consider the sub-workflow steps until it reaches the sub-workflow You may wish to pass attribute values from the parent workflow to the sub-workflow to branch conditional statements. There are many options available, and the expression builder is quite flexible. • Both maps must contain compatible data types (for example, text popup or integer field). • You may have different attribute names in the parent and sub-workflows. • Popup data types must have identical values in the parent and sub-workflows, but field data types will work with only partial matches. For example, you may use the starts with, ends with or contains options. VALUES to affect conditional statements in the sub-WF: make sure you discuss “mapping” the different attributes and how the attribute values must have identical names in the main and sub workflows (or, in the case of strings or fields, start with the same name if you use the “starts with” parameter in the evaluation step). “End with” and “contains” are also options.

Settings & Discussion

Performance Hit?

One of the largest performance hits on Livelink workflow is using multiple, large forms with workflow and passing the form data to sub-workflows. When you pass data from a parent WF to a sub WF (attribute data or form data), Livelink creates a copy of the data in the database table and assigns the new subworkflow ID to the row(s). For simple forms (5-10 attributes or form fields) this is efficient, but is less so with multiple forms and/or larger number of fields. With more form fields, this could mean the system takes more time to complete the sub-workflow initiate step. Something to consider when designing workflows and evaluating performance implications.

Page 15: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 15 of 21

Exporting Once a workflow is ready to be migrated, the Livelink administrator can browse to the workflow and select the EXPORT bar from the function menu. The template is exported to a designated location in the form of an ASCII text file. Then in the new environment, a new workflow is created. The exported workflow can be imported into the newly created workflow by selecting the IMPORT bar from the function menu. In the resulting dialog box, the administrator can select the exported ASCII file as the imported object. Exported maps usually have a .txt extension For more complex workflows, there are some parts of the migration that may require additional procedures. For example, there are some additional steps that need to be taken when attachments are part of the workflow, and some complications may arise if roles are involved. Custom categories and attributes have new node ID’s associated with them in a new instance, so if they are associated with a workflow, there may be resulting errors. In addition, special consideration must be taken when migrating workflows that have associated dependencies, sub-workflows, form templates, or named assignees. Workflows and LiveReports Both the Workflow Design II course and the course dealing with Advanced Schema a Live Reports covers the topic of Workflows and Live Reports in detail, however, the following table has some abridged information to get the curious report writer started.

Settings & Discussion

Exported Map

Exported Workflow Maps are exported with a <dot> map extension, however, the operating system will regard it as a text file thus maps often have a name like “map_name.map.txt”. What is the format of the exported map file? The exported Workflow Map definition is stored as an Oscript LIST.

Some abridged Workflow Information to Assist in Creating Live Reports

User Input Desired Value Example LiveReport How to Supply the Value

[MapID] The unique id of the workflow map from which a workflow was initiated.

Number of Late Workflows By [Map ID]

To learn the unique id of a workflow map, CLICK its functions icon and SELECT Status. This will take you to the map’s Workflow Status page. In your browser’s address bar, you will see a URL, ending with the text mapid=[####]. The number specified is equal to the map’s unique id: COPY this number into the Map ID field of the livereport.

[ID] The unique id of a workflow.

Workflow Steps and Status By [ID]

To learn the unique id of a workflow instance, on the My Workflows<Status page, POSITION your cursor over the workflow’s name. Within the status bar at the bottom of your web browser, a pair of numbers, enclosed in parentheses, will display. The first number in this sequence is equal to the workflow’s unique id. COPY this number into the Workflow ID field of the livereport.

[Performer] The unique id of a Livelink user.

Number of Active Steps By [Performer]

For this type of report, Livelink provides you with an interface for selecting the workflow assignee–you simply CLICK the choose user

icon and SELECT a Livelink user.

Page 16: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 16 of 21

Process Automation Step Go to the admin pages, once you have completed your installation, and verify on the Administer Object and Usage Privileges page that all Item Handler privileges are unrestricted or more correctly set to those that need to design and edit maps. Also in the admin pages, on the Configure Workflow Agent Parameters page, verify that you have just a sleep interval specified. The process step, like the Item Handler step, will automatically perform its task when it is executed during the course of a workflow. However, the tasks performed by the process step are not focused entirely on document and item management, as they are for the Item Handler step. All of the following can be automated by using a process step in a workflow: • Send an e-mail to an address of your choice, either to a Livelink user or an external address. • Add comments to the work package. • Define default values or set new values for workflow attributes. In the Message field, you can incorporate any of the options described below: • You can use replacement tags: Include information about the initiator, initiated date or workflow name in the subject and message. Refer to your user help for more information on these tags. • You can copy and paste URLs to workflow attachments, Livelink items, or to an Add New Item page in the work package in order to prompt the recipient to perform a certain action in your Livelink system. If you choose to include a URL to an item in Livelink, then the e-mail recipient needs to be a Livelink user in order to process the URL. The following table should help illustrate where use of the Process Automation Step is suitable:

Need to Use THIS Step

Move or copy a document from a workflow to a Livelink repository, or vice versa

Item Handler

Send an email message Process Automation Add comments using Attributes Process Automation Update a version of a document in the Attachments folder with a version from Livelink, or vice versa

Item Handler

Update a workflow attribute with a static value, such as a null value, or another default value

Process Automation

Update a workflow attribute with the value from a document’s category attribute.

Item Handler

Add a category to a Livelink item, and update the category attributes with values from the workflow attributes

Item Handler

Create an automatic folder hierarchy Item Handler

Settings & Discussion

The process step also has a feature to copy items from the Attachments folder. This functionality has been superseded by the Item Handler step. It was left in the process step interface only for those customers that had customized this feature in previous versions. If you have item management needs, be sure to use the Item Handler step instead

Page 17: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 17 of 21

Item Handler Step Use multiple Item Handler steps: There is no limit to the number of Item Handler steps that you can employ in a workflow map. Multiple Item Handler steps are necessary in the following scenarios: • A step must occur in-between the processing of an Item Handler’s operations. For example, after an Item Handler updates a document with a new version, an evaluation step will determine whether the new version is approved before passing the document to another Item Handler that is configured to move the updated document into the Enterprise Workspace. • You need to plan the order of your automated events. For a single Item Handler step, it will perform automated events based on the order of the Tabs, namely: Folder Creation -> Categoeried -> Versioning -> Copy /Move. For example, if you needed the step to first create a new folder and then movie or copy material into that folder, this could be done in one step. If that same step required a folder to be created, then files moved into that new folder and lastly a new version added to a document, this would need at least two separate Item Handler steps. When an Item Handler is reached in an executing workflow, its operations become ready for processing. However, one of the following must begin the Item Handler’s processing: 1. The workflow agent. The workflow agent processes ANY User Step that you designate in the background. In order for an Item Handler step to be PROCESSED by the workflow agent, the map designer must check the option to Execute using Workflow Agent on the Item Handler’s General page. In addition, the Item Handler must be assigned to a Livelink user. Additionally, the user must have permissions (as defined on the Administration pages) for workflow agent privileges. By default only the Admin user has these privileges. 2. A Livelink user: When an Item Handler is not configured to execute using the workflow agent, or when the Item Handler encounters an error, the Item Handler step will be sent to the MY ASSIGNMENTS page of the user assigned to the step. This user must open the step and click its button in order to process the Item Handler, and send the workflow on to the next step. You may want to wait until you have finished testing a workflow map before you check the option to Execute using Workflow Agent. Otherwise, you will have to wait for the workflow agent to process the step before you can continue testing the workflow. When the Item Handler executes, it checks to see how you have chosen to link the data between workflow attributes and category attributes on the Definitions page. The Operations page then dictates what kind of data transfer is performed. To define an operation, you will need to configure the following sections on the Add Operation page. • Item: Targets an item in Livelink, a workflow attachment, or an item that has been selected via an item reference attribute. In Livelink version 9.5, you may also target a folder definition, if one is available. The update options will be based on this item. • Update Options: Specifies whether the category on the specified Item is getting updated, possibly with the current workflow attribute values, or whether the current workflow attribute values will be updated by the specified Item’s category.

Note that the specified target must be explicit and a single target. Many people get confused and they think that by specifying the Workflow Attachment Folder as the target, whatever documents are present in the Attachment Folder will have their category and attribute values updated, but that's not how it works. The only way to specify the doc dynamically during workflow execution is to have an Item Reference Attribute which will need to be populated by a user prior to the desired operation.

Settings & Discussion

Item Handler Step

The ability of the Item Handler to target a folder definition is the only NEW feature in 9.5, which was not available in 9.2 sp1, with the workflow upgrade.

Be Careful Using Process Automation

Be careful using Process Automation to make generations of documents. If the generation already exists, you will get an error message. Unfortunately, there is no option to change the generation name. If no release or revision exists, and you create a generation to a compound document you will get this error: Livelink Error: Error performing Workflow operation. [Cannot create a Generation of a Compound Document with no revisions/releases.] A Target needs to be a Livelink container, as defined by an item reference attribute otherwise you will get runtime error: ”Target is not a container node”. If the item already exists in the target folder, you will get runtime error: “Item with XYZ name already exists”. To avoid this , rename the source.

Page 18: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 18 of 21

• Item Handler will update the category information on the Item you’ve specified, according to the following options:

• Remove Categories: will delete the categories specified on the Definitions sub-tab from the Item you’ve specified.

• Add Categories: will add the categories specified on the Definitions sub-tab to the Item that you’ve specified.

• Set Attribute Value(s), will update the category attribute values on the Item you’ve specified with the corresponding workflow attribute values that you defined on the Definitions sub-tab.

Testing Testing your workflows can be a time consuming process. The following are suggestions to assist you in developing your test plans and scripts. For initial testing, you may wish to assign all steps to the Initiator. Be aware that although this may speed the testing of the workflow, it may also result in some unexpected surprises when the workflow is moved from a development to your production environment. For example, if the workflow is only tested as a user with System Administration Rights, it is unlikely you will encounter errors in using the Workflow Agent for Item Handler processing for moving or copying documents and other operations. However, remember the user assigned to the Item Handler will have to have the proper permissions (as well as the appropriate privileges) on the target destination for these operations to perform successfully. Testing and refinement of the workflow should focus on two areas. The first is functional testing, to verify that the workflow is error free and performing as expected. The second area of testing is end-user testing, to verify that the assignments are clear to the end-users, and that they can complete their workflow assignments effectively. The results of testing will likely cause modifications to be made to the workflow. An iterative process of retesting and modification will be necessary until everything is working to the design. Functional Testing The following functional tests should be completed: • Map Verification: Verify the workflow map using the ‘Verify Map Definition’ function. This will help identify mistakes or omissions. • Routing: Verify the routing for conditions to make sure everything is flowing as designed. Open Text Workflow Designers often call the route testing "permutation testing", which is a fancy way of saying test all available, possible routing options. Testing of step durations can also be conducted at this stage, however, Map Designers may prefer to put this testing together with end-user testing since it is end-users who will provide the feedback that "step X should take Y days". • Visibility: Verify that all performers have access (or are denied access) to all data elements as designed. This should include attachments, attributes and comments • Storage: Verify that resulting documents and metadata are stored correctly at workflow completion. This will include a verification of the permissions on the folders targeted by any Process Steps. The same is true of Item Handler Steps. Whoever the step assignee is, they need to have adequate permissions for the operations performed on specified objects. • Management: Verify that LiveReports are producing intended results. Additionally, verify users (or groups) who have management permissions to the workflow have the appropriate level of access. • Item Handler Step: When using the Item Handler, you may wish to wait to assign the steps to the workflow agent until after the workflow has been thoroughly tested manually. This could speed up your testing.

Settings & Discussion

Page 19: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 19 of 21

End-User Testing The following end-user tests should be completed: • Instruction Review: Verify that users understand the instructions and can complete the assignments correctly. Verify the instructions and package information appear correctly on each step. This could include verifying the comments were passed from one step to the next, the Delegate, Send for Review and Authenticate functions appear as appropriate and the Attachments, Attributes and Form values are passed and appear correctly in each step. • User Involvement in Testing: Get end users involved in testing at the appropriate time. Getting end users involved too early can lead to frustration and possibly a lack of interest in using the tool. Getting them involved too late can result in lack of user adoption. • Solicit feedback from end users. Have the users attempt to complete the workflow steps based on a limited overview of workflow assignments to see if the instructions were clear enough and was it easy for them to figure out what to do, where to click etc. • Disposition Review: Verify that users understand the disposition choices for evaluation steps. Problems During Testing? When testing your workflows, you may encounter some problems or not get the results that you anticipated. Should this situation arise, consider the following questions: • Did the step performer have sufficient map management permissions? For example, if the workflow is supposed to delete, did the final performer have delete permissions on the items in the Workflow Attachment Folder? • Similar to the above, did the workflow instance disappear on completion? If so, was the map configured to auto-delete on completion? •If the workflow agent did not process an Item Handler step, consider the following: Did the map designer remember to check the Execute using Workflow Agent checkbox on the Item Handler step? Has enough time elapsed for the workflow agent to process? Does the user assigned to an Item Handler step have the appropriate privileges? • Was a true path defined for all possible paths in an evaluation step; and if not, was a false path configured? • If an evaluation was based on attributes, and the evaluation failed, was it because the attribute being used to route the workflow was never required prior to the evaluation step? • If the map designer assigned a step to a group, were the Group Options set correctly? If there was a disposition on the step, was the Group Step Tabulation configured correctly? Remember, in many cases, the workflow is designed so that a user selects the performer of a step via user attributes or role implementation. In the event that a user selects a group, then the designer must consider what the appropriate Group Options should be. • Permissions on supported object and Workflow Packages. If a user cannot see a document that has been added to the workflow Attachments, does the that user (or group) have permissions to the Workflow Attachments folder? If using Forms, does the user (or group) have See and See Contents permissions on the Form Template? If using e-Sign, does the user (or group) have Reserve permission on document that is to be signed? • If Attributes were used, were the attributes specified with the proper setting on the step (Editable, Read Only, Required, etc.)?

Settings & Discussion

Not Exhaustive List

The list on this page provides examples of common design errors for your consideration. It should not be considered an exhaustive list.

Page 20: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Livelink™: ECM Workflow and Best Practices Page 20 of 21

Workflow Validation • Map Verification - Verify the workflow map using the ‘Verify Map Definition’ function. This will help identify mistakes or omissions. If the Workflow Map has been imported from another Livelink System, it is a good idea to double-check the Item Handler Steps within the imported Workflow Map. • Completion Actions – Ensure that a completion action is selected, either ‘Archive on Completion’ or ‘Delete on Completion’. This will alleviate the need for the workflow manager to clean up completed processes. Message Meaning

Verify Map Resulting Message Message Meaning No step assignee There is no assignee for the User Step. No step name defined There is no name for the step. The Evaluate step uses criteria that no longer appear in the map definition

The criteria required to evaluate the step is no longer available or is invalid.

No attributes defined You have information dependent on attributes that have been deleted.

No evaluate conditions No conditions are defined for the evaluate step. No step duration There is no duration set for the step. No problems detected There are no problems detected with the workflow.

In Livelink, you can quality check your workflow map for certain errors before it is initiated. To check a workflow map for errors, choose Verify Map Definition from the Map menu when you are designing the workflow map. Livelink will check for errors such as: • Unassigned steps. • Steps with an undefined duration. • Evaluations that do not exist or are invalid. • Steps without names. If no errors are found, the message No problems detected is displayed. In addition to using the Verify Map Definition function, test your workflow map before putting it into production. To test the workflow, initiate it one or more times with fictitious processes, watching the work move from step to step and verifying that it looks and behaves as you expect. Create and test your workflow maps in a development environment.

Settings & Discussion

Page 21: Application Note - Livelink 9x Workflow Best Practices - Version 1-1.pdf

Application Note

Sales Americas Europe Asia/Pacific

www.opentext.com [email protected]

North America Sales 1-800-499-6544

International Sales +800-4996-5440

United States 100 Tri-State Int’l Parkway

Lincolnshire, IL USA 60069

Phone: 847-267-9330 Fax: 847-267-9332

United Kingdom Grosvenor House

Horseshoe Crescent Beaconsfield,

Buckinghamshire United Kingdom HP9 1LJ Phone: +44 1494 679700

Fax: +44 1494 679707

Germany Technopark 2

Werner-von-Siemens-Ring 20 D-85630 Grasbrunn

Germany Phone: +49 89 4629 0 Fax: +49 89 4629 1199

Australia 138 Harris Street

Pyrmont, NSW 2009 Australia

Phone: +61-2-9552-3334 Fax: +61-2-9552-3446

© Copyright 2007 Open Text Corporation. All rights reserved. Livelink, Livelink ECM, are trademarks or registered trademarks of Open Text Corporation. All other trademarks or registered trademarks are the property of their respective owners.

We trust that this Application Note and a review of Workflow best practices, recommendations and suggestions for the designing, editing and managing of Livelink 9.x workflows was helpful. While most of these best practices applies to most Livelink 9.x systems, this documentation has been written against versions 9.5 SP1, 9.6 and 9.7.

Results and Findings

Colin T. Sim, Senior SDK Support Specialist (Certified Livelink SDK Developer & System Administrator), Open Text Corporation, Customer Support, Waterloo Ontario Canada Email: [email protected] or [email protected] Phone: 1-800-540-7292 \ 519-888-7111 x 2295 My sincere thanks and gratitude is extended to the following contributors to this Application Note for reviewing its content and providing invaluable feedback: Tammy Jakubowski Product Designer Open Text Development Eric Saavedra, Lead Consultant, Open Text Global Services Laurie Goldberg, Product Manager Open Text Reference: 9x-120: Workflow Design I. Open Text Learning Services. Release 1.0, 08 Feb 2005. 9x-220: Workflow Design II. Open Text Learning Services. Release 1.0, 04 Feb 2005. 9x-221: Workflow Design III. Open Text Learning Services. Release 1.0, 29 Aug 2005. 9x-223: Designing and Implementing Livelink Forms. Open Text Learning Services. Release 1.0, 02 Mar 2005. 9x-224: Livelink e-Forms Management Design. Open Text Learning Services. Release 1.0, 02 Sept 2005. (*) It is assumed that readers of this document have previously attended the appropriate Livelink training classes or have an equal level of practical experience.

Credits, Trademarks

and References