Adding, Editing, Deleting Categories

In the list of categories, click on the category name to edit or delete. Use the Add button to add a new category. When adding a new category, a template category must be specified. CATSWeb copies the field definitions from the template category to the new category. The category name is limited to 50 characters. You can choose to limit who can modify the category by specifying ownership.

Managing Field Definitions

Click the Field Definitions button to view and edit the Field Definitions for the category.

Back to Top

These settings apply to all Category types:

• Category - The name of the Category, which is often referred to as the Form Name. Users will refer to the form by this name.
  
  
• Columns - Specifies the number of columns in the form or dashboard template. Separate settings are available for each applicable form type (e.g., Issue Form, Disposition Form, Query Form).
  • Special settings apply to forms that are displayed on mobile devices.
    
    
• Child Record Display Style - Specifies the format for child record display (Notes, Attachments, etc.). Applies only when using CSS Interface Preferences.
  • Original: Uses the CATSWeb classic child display. Child records are displayed as sections below the Parent record.
  • Table Rows: Individual child record types are displayed in separate tables, which are always displayed, Individual child records (such as Notes or Links) are displayed as separate rows within each table.
  • Tabs: Individual child record types are displayed within individual tabs. When a tab is opened, the individual child records (such as Notes or Links) are displayed as separate rows within a table. For tabs that are not opened, the child records are not displayed.
    
  
  
• Field Restriction Mode - Specifies how Field Access Restrictions work for the form. Allow then Deny means that all users are allowed full access to all fields unless a Field Access Restriction is put in place that denies them some or all capabilities. Deny then Allow means that no users are given any access to any fields unless a Field Access Restriction is put in place that allows them some or all capabilities.
  
  

  Important

  If you choose to set the Field Restriction Mode to Deny then Allow, you must add Field Access Restrictions that grant everyone access to a variety of System Fields on the form. If you do not do this, users will experience errors when the form loads or when it is submitted. AssurX recommends that you set the Field Restriction Mode to Allow then Deny to ease administration.

  
  
• Functional Restriction Mode - Specifies how Functional Restrictions work for the form. Allow then Deny means that all users are allowed full access to the form unless a Functional Restriction is put in place that denies them some or all capabiities. Deny then Allow means that no users are given any access to the form unless a Functional Restriction is put in place that allows them some or all capabilities.

Back to Top

Some category types have special settings available. These settings include:

• Default {record type} Category - Issue categories allow a Default Action Category to be specified. This enables you to designate a default Action category for the Issue category. When a new Action is created from an Issue (via the Create New Action link), the new Action will automatically default to this category. If a Default Action Category is not specified, the new Action will use the default Action category for the Employee's Department.
  
  Similarly, Action categories allow a Default Subtask Category to be specified. This will be the default category that appears in the pull-down list associated with the Add Subtask area on Action records.
  
  
• Disposition Step Enabled - Available only for Issue categories. When the Disposition step is enabled (checked) Issues in the category go through a 3-step workflow process:
  • Entered, assigned to an Employee for Disposition
  • Disposition entered, awaiting Action assignment
  • Action assigned
    
    When the Disposition step is disabled (not checked), Issues in the category go through a 2-step workflow process:
    
    
  • Entered, assigned to an Employee for Action
  • Action assigned
    
    
• Effectiveness Available for Status - Available only for Action categories. This setting can be used to control when (if ever) during the Action's workflow process the Enter Effectiveness/Edit Effectiveness link is present. Check the status values in which the link is desired. Some applications will not utilize the Effectiveness feature at all, and all boxes can be unchecked to disable it.
  
  
• Grant Category Permissions - This setting is only available when a new Issue, Action or Subtask category is being added, and only if the InstallCategoryPermissionOptionForNewForms.mdb script has been executed against your system (new in Build 16f). If checked, CATSWeb will grant Category Permissions for the new category to all existing Employees and Personalities in the system. This is also the default behavior when the setting is not available.
  
  If unchecked, CATSWeb will not grant Category Permissions to any existing Employees or Personalities. The form will be "invisible" in the Add Action and Add Issue category lists until Category Permissions are granted.
  
  
• Prefill Fields - The Prefill Fields setting can be used to configure automatic copying of field values from a record into the Add form for a related record type. This setting is available in the following instances:
  • Issue Forms ("Prefill Fields for New Actions") - Issue records eventually progress through the workflow to being assigned to Action records. In many instances a new Action record is created for the Issue via the Create New Action link on Issue records. This setting allows field values from the Issue record to be copied to the form used to add the Action record.
  • Action Forms ("Prefill Fields for New Subtasks") - Action records may have Subtasks associated with them. This setting allows field values from the Action record to be copied to the form used to add Subtask records.
  • Subforms ("Prefill Fields [from parent]") - Subform records are added from parent Issue, Action or Subtask records. This setting allows field values from the parent Issue/Action/Subtask record to be copied to the form (or Add Row in this special case) used to add Subform records.
    
    Field pairs are designated using this format:
    
    DestinationTableFieldName=SourceTableFieldName
    
    Multiple field pairs may be included, and each pair is separated by the "|" character. The field names used must be the actual field names from the underlying CATSWeb database tables, rather than the field captions which are arbitrarily assigned in the field definition pages. There are several methods of determining what these field names are:
  • Field Definition List - View the field definition list and use the value stated for the Table Field.
  • Query Form - An ad-hoc query can be entered and submitted with the optional Show SQL statement generated box checked. Be sure to enter data in the query field of interest. The query output will show the actual SQL statement generated, which will include the SQL WHERE clause with the actual table field names.
  • Other Tools - Database management utilities, Microsoft Access, and many other tools allow the underlying table structure to be viewed.
    
    
• Standard Subtask Listing - This setting is only available for Action forms, and determines if the standard Subtask listing is included when Action records are viewed. Administrators may prefer to disable the standard listing and create customized Subtask listings using Display Parts, if the Dashboards option is installed.
  
  
• Unavailable Subtask Categories - This setting is only available for Action forms, and allows subtask forms to be selected that are not present in the Add Subtask list, even if a user has been granted Category Permission to the subtask form. The setting does not prevent subtask records in the selected forms from being added to actions via the CATSWeb API or other means. If the subtask form name (category value) contains commas, it may not be selected in this list, since multi-select lists use the comma as a delimiter.
  
  

Back to Top

Signature Controlled Operation Settings

Signature Controlled Operations can optionally be enabled for each category. Each operation is individually configurable. For more information on the available operations and how they are used in the workflow process, read this topic.

• Signature Request Routing - This setting is only available if the optional Serial Signature Requests feature has been installed. It allows Serial or Parallel routing to be chosen for signature requests. When the Serial Signature Requests feature is not installed, all signature requests use Parallel routing. For more information on the differences between Serial and Parallel routing, and how to properly configure the remainder of the signature controlled operation settings for Serial routing, read this topic.
  
  
• Active - Check this box to make the signature controlled operation active.
  
  
• Majority Approves - Check this box if only a simple majority of the signature requests need to be satisfied, instead of requiring that all signature requests be satisfied.
  
  
• Required Signature List - Specifies the CATSWeb List that contains the Employee Names of users that are required to apply their signatures to complete the signature controlled operation. Each of these users will receive a signature request task and an E-mail notification message when signatures are requested for this operation in any record in the category (for Parallel Signature Requests), or when their request becomes active (for Serial Signature Requests). This setting is not required for Parallel Signature Requests if an entry is made in the Required Signature Name Fields box described below. If the list contains any invalid Employee Names, the invalid names will be ignored.
  
  
• Signature Type - The type of signature that a user must apply to satisfy a signature request. Available Signature Types are specified in the Signature Types List. Select the blank entry to allow any signature type to satisfy a signature request.
  
  
• Signature Request Field - The field on the form that will serve to track the status of this signature controlled operation. CATSWeb will automatically transform it to a set of option buttons with selections such as Signatures Not Requested, Signatures Requested, etc. Administrators should modify the field's caption to agree with this usage, by setting it to "Preliminary Disposition Approval Status" or something similar. Employees with the appropriate permissions will edit this field to trigger the signature request process.
  
  NOTE: If you require signatures to be requested as soon as a new record is added, a special default value can be used in the field definition (and the field can be designated as non-editable or invisible).
  
  
• Due Date Increment - The number of days in the future that the signature requests will be due.
  
  
• Notification List (When Last Signature Applied) - Specifies an optional CATSWeb List containing the Employee Names of users that wish to be notified via E-mail when the final requested signature is added. See also the Notification Name Fields setting below.
  
  
• Required Signature Name Fields - This setting can be used to specify one or more fields in the underlying data record that contain Employee Names who are required to apply their signatures to complete the signature controlled operation for that record only. Each of these users will receive a signature request task and an E-mail notification message when signatures are requested. Invalid Employee Names will be ignored. The actual field names from the underlying data table must be specified, not the arbitrary field captions. Multiple field names should be separated by the pipe character ("|"). This setting should not be used for Serial Signature Requests. If any of the fields will contain multiple comma-delimited names, those fields must be bound to multi-select lists via settings on their field definition pages .
  
  Note the difference between this setting and the Required Signature List setting described above. The Required Signature List setting allows for a static signature process in which the same list of people must approve every record in the category. This setting (Required Signature Name Fields) is designed for a dynamic approval process where the names of the required approvers are contained in each record, and can therefore vary from record to record. These two techniques (static and dynamic) can also be combined by specifying both settings. For each particular record, CATSWeb will then require signatures from all the members of the list, and from whatever names are present in the Required Signature Name Fields for that particular record. Serial Signature Requests may also be used to implement a static, dynamic or hybrid static/dynamic approval process.
  
  
• Notification Name Fields - Used in a way similar to Required Signature Name Fields above, Employee Names in specified table fields will receive an E-mail notification when the final signature is applied that completes the signature controlled operation. This notification will be sent to these names and any names contained in the optional Notification List described above.
  
  
• Record Edit Restrictions - This setting determines if the record can be edited during various stages of the signature controlled operation. When editing of the record is disabled, the record is considered to be locked. The setting may also specify actions CATSWeb will perform automatically when the last signature is added:
  
  
  • Normal - Editing of the record is allowed throughout the signature controlled operation.
  • Locked While Signatures Outstanding - Editing of the record is disabled from the time that signatures are requested, until the last signature is applied. This setting ensures that all signatories see the same data in the record at the time they sign it.
  • Locked Until Next Stage - Editing of the record is disabled while signatures are outstanding, just as if the Locked While Signatures Outstanding setting were in place. In addition, editing of the record remains disabled until it is moved to the next stage of the workflow process.
  • Locked Forever - Editing of the record is disabled as soon as signatures are requested, and the record remains locked forever. This setting should only be considered for signature controlled operations that occur at the end of the workflow process.
  • Auto Complete on Last Signature - This special option is only available for the Completion Approval operations on Action and Subtask forms. When set, the Action or Subtask will be automatically completed when the last signature is added. After completion, it is left unlocked so that it may later be closed.
  • Auto Close on Last Signature - This special option is only available for the Closing Approval operations on Action and Subtask forms. When set, the Action or Subtask will be automatically closed when the last signature is added. After closing, it is left unlocked. Employee Permissions that govern normal manual closing of the records are ignored for the user that happens to add the last signature.
  • Auto Close/Lock on Last Signature - This special option is only available for the Closing Approval operations Action and Subtask forms. When set, the Action or Subtask will be automatically closed when the last signature is added. After closing, the record is locked. Employee Permissions that govern normal manual closing of the records are ignored for the user that happens to add the last signature.
    
  When a record is locked as the result of a signature controlled operation, authorized users who have been granted the appropriate Unlock permissions are given an option to unlock the record. Unlocking a record is meant to be an "emergency" operation rather than something that is routinely done.
  
  > When a record is unlocked, any outstanding signature requests are deleted, and the current signature controlled operation is reset to Signatures Not Requested. Previously completed signature controlled operations may also be reset, depending on the context. Signatures from users that signed the record prior to it being unlocked will still be present, but these users will have to sign the record again after signature requests are reinitiated.
  
  > Judicious use of CATSWeb Proxy Signature capabilities should eliminate almost all requirements for a record to be unlocked.
  
  
• Child Edit Restrictions when Parent Locked - This setting determines how child records such as Notes, File Attachments, etc. are handled while the parent record is locked. Note that tags are not affected by this setting. If you wish to restrict the adding of tags based on signature control status, use a conditional functional restriction instead. The Child Edit Restrictions when Parent Locked setting has the following values:
  
  
  • Normal - Adding, editing and deleting of child records is allowed.
  • Edit-Delete Prohibited - Editing or deleting child records is prohibited.
  • Add-Edit-Delete Prohibited - Adding, editing or deleting child records is prohibited.
    

Back to Top

Event Hooks, Functional Restrictions and Child Subforms

Multiple Event Hooks, Functional Restrictions and Child Subforms may be added to each category (Child Subforms are not applicable to Subform categories).

Category (Form) Design Tips

Here are some general tips to assist you in optimizing your form design.

Back to Top