top of page

Framework Features

1.0 Overview

The application framework (framework) controls the user interface. The more sophisticated the framework, the more features users will be able to enjoy.

This section discusses the mandatory and desirable features within the framework.  For a demonstration of these features, please check out this youtube video.  

2.0 User authentication

The framework will provide a method for users to sign in and authenticate themselves. The other requirements of the user authentication engine from a framework perspective are as follows:

  • Ability to use other authentication services.

  • Ability to set and enforce password policies.

  • Ability to time out sessions.

  • Ability to change passwords.

  • Ability to track authentication attempts in the change history.

3.0 Menu Options

3.1 Introduction

This section of framework features discusses features built into the framework for users to initiate actions for menus. These features aim to help users find what they need to access in a methodical manner, while providing fast and efficient ways to initiate menu options.

3.2 Hierarchical access to menus

The framework will need to provide hierarchical access to menus so a user can drill down from high-level subjects and eventually get to the menu option of interest. In large systems, thousands of menu options can exist, making this task complex. The menu options may appear on a page, in a drop-down menu, or in any other method that allows users to drill down and select the right option.

3.3 Provide fast and efficient ways of accessing menu options

The framework should provide fast and efficient methods of finding menu options, such as:

  • Entering a menu number/name directly (desirable).

  • Browsing insert menu options and selecting one to execute (e.g., insert contact, insert invoice, etc.).

  • Browsing data maintenance options and selecting one to execute (e.g., maintain contacts, maintain assets).

  • Using hotkeys to access frequently used menu options (desirable).

  • Presenting users with their previously selected menu options so that the user can quickly select menu options of interest (desirable).

  • Allowing users to create a favorites list of menu options (desirable).

3.4 Multi-lingual captions, tool tips, help text

The framework will present the captions, hover text, and help text from the command system based on the user’s language preferences (desirable).

3.5Security

Users will only see the menu options they are permitted to view based on their user privileges.

3.6 Tracking command history

Whenever a user invokes a command from menu  (such as maintain contacts), the system will check to see if the command is tracked in change history.  If so, the system will automatically generate a change history record that records the user that invoked the command, the date/time, the id of the command/menu option they invoked.

4.0 Search/browse data

Some menu options will cause creating an action tab in the form of a search/browse tab. Typically, a search form will qualify the results set coming back from the database. However, in some cases, the initial search tab is not required. Below is a description of the search and browse capabilities.

 

4.1 Search form

  • The search form limits the data retrieved from the database which appears in the browse form.

  • Parameters stored in the database determine the search form’s construction.

  • The search form fields will be in the form of text boxes, single pick lists, multi-pick lists, or checkboxes.

  • The user’s language preferences will determine the captions extracted from the database (desirable).

  • The search forms for temporal data should allow the user to override the default query date for the current search form.

 

4.2 Browse form

The browse form presents a grid with the data returned from the database based on selected search form results. The user can toggle between the search and browse forms to alter the search results they are viewing. Ideally, the browse form will be a scrollable form that will react to up and down arrow keys and page up and page down keys. 

 

The framework should provide users with the following features from a browse form.

 

4.2.1Creation of browse form

The browse form should be fully constructed based on information from the database. This includes:

  • Presenting the columns in the appropriate sequence, which is either based on the default or the user’s previous preferences.

  • Presenting column headings based on the user’s language preferences (desirable).

  • Presenting columns with the appropriate widths based on the default or the user’s preferences (desirable).

  • Presenting the grid in the appropriate sort order.

  • Presenting the user with all the menu options that are available for the browse (e.g., add, edit, delete, drill down, export, etc.).

The browse form will need to retrieve its data from a programmatically generated view based on browse form parameters.

4.2.2 Filtering data in the grid

The browse form should support filtering based on one or more columns. The filter should include options such as equals to, contained in, not contained in, etc (desirable).

4.2.3 Personalize the grid

The browse should allow users to personalize grids in the following manner:

  • Click on columns to change sort order.

  • Rearrange the sequence of columns in the grid and hide/unhide columns (desirable).

  • Pin columns to the right or the left (desirable).

  • Pin rows to the top or the bottom (desirable).

  • Create rules for conditional formatting of columns (e.g., highlight cells/rows with a particular font color or background color) (desirable).

4.2.4 Paging feature

The browse form should support paging. Paging only returns the first page of data on the initial query but allows a user to navigate through results and navigate to the first and last page of data (desirable).

 

4.2.5 Export data

The framework will support exporting to a spreadsheet, PDF, or document. The user should be able to select all rows or rows for export.

 

4.2.6 Take actions on rows

The browse form should provide various methods for taking actions based on the data in the grid, which in turn is based on their security privileges. These methods include:

  • Using the menu bar to select a menu option to execute for the selected record(s).

  • Using short-cut keys to access menu options directly (desirable).

  • Right-clicking on a row and seeing a context menu appear, which shows all options available for the current row (desirable).

  • Clicking on a row and having either a view or edit form open (desirable).

  • Clicking on a hyperlink foreign key value in the grid and opening either a view or edit form (desirable).

  • Supporting the ability to edit multiple records (desirable).

 

4.2.7 View related data (drill down)

One of the common actions on the grid is to support the ability to view related drill-downs. For example, a user can right-click on a row and a context menu will appear, showing all the drill-down options. One of the more popular options for the drill down will be to view the change history for the selected record.

 

4.2.8 Take actions on multiple records at one time

The browse form should allow the user to select multiple records and take action. An example is multi-edits, where a user can select multiple rows and make an update to a specific column. The security system will control the ability to perform multi-edits. The change history log tracks updates (desirable).

 

4.2.9Mail merge engine (Desirable)

The browse form should support a connection to the mail merge engine for any forms with a link to the contact. The mail merge engine allows a user to process all rows or selected rows in the browse list. The user can then either create a new mail merge document or select an existing document.

The mail merge engine will take contents from the browse columns and insert them into the mail merge document as required.

For more information on the mail merge engine, refer to the mail merge administration section later in this chapter.

 

4.2.10 Edit data directly in the grid (Desirable)

The browse form should support data editing directly in the grid for both master and detail data. It will process the updates according to business rules from the database and will capture updates in the change history log. The ability to edit will be controlled by whether a user can edit within the grid or not.

4.2.11 Master data with detail tabs (Desirable)

The browse form should support browsing of child data for records if they exist. For example, if we are browsing for data about projects, we can see child tabs at the bottom of the page, such as activities performed for the project, resources assigned to the project, etc. Furthermore, the user can click from one child tab to the next to see different child records.

 

4.2.12 Advanced features of the grid (Desirable)

The browse form may include advanced features for users, such as:

  • Creating a pivot table and/or graph directly from the grid.

  • Viewing the grid result on a map if latitude/longitude coordinates are available.

  • Performing a mail merge from the grid if the grid contains information for a contact.

 

4.2.13 Save search criteria and formatting to a favorites menu (Desirable)

The framework should allow users to save search criteria and formatting to a favorites list so they can access it later.

 

4.2.14 Manage formatting (Desirable)

The framework will allow system administrators to create a new default format and delete existing ones for users (if removing a column from the column list, for example). It also should allow users to change their formatting to the default format.

4.2.15 Tracking command history

Whenever a user invokes a command from menu  (add, edit, delete, view, etc), the system will check to see if the command is tracked in change history.  If so, the system will automatically generate a change history record that records the user that invoked the command, the date/time, the id of the command/menu option they invoked and the table/id of the record they were affecting.  The system will automatically return a change history id, which will be recorded on any records that are inserted or edited.  

5 Edit form

The framework needs to provide the ability to edit data in a form mode. The form can have multiple dynamic tabs based on a user’s security setting and the nature of the edited record. The form must be used in Add, Edit, Delete, and View modes.

New edit forms will be opened with a caption based on the command executed plus context information (e.g., name of contact). The form should include some type of indicator (e.g., *) to indicate that the record needs to be saved.

 

The data on the edit form should not be written to the database until the user presses a save button. This includes inserting, updating, and deleting child data in tabs. A data maintenance utility that is a function within the database accomplishes this task. The front-end layer will call the data maintenance utility in read mode, which will return an object in a document format that includes data for the main entity plus all the child entities.

 

The edit form will modify this data object as it requires. This could be modifying the main entity and/or adding, editing, or deleting any of the records for child entities. When the user presses the save button, the front-end layer will call the data maintenance utility in update mode. This will cause it to compare the revised data object with the database and make all the necessary inserts, updates, and deletes within a transaction.

 

5.1 Creation of edit form

We construct the edit form primarily from information held in the database. This includes:

  • Placing the controls in the right location on the form with the appropriate caption based on the user’s language preferences (desirable). Examples of controls are tabs, grids, and various types of column controls (text, date, single pick list, multi-pick list, radio control). In addition, the edit form should support custom controls to support specialized needs.

  • All business rules for processing, navigating, and validating data columns should be retrieved from the database with the ability to have custom rules.

  • The framework can create forms dynamically from the database, precompile forms to improve performance (desirable), or a combination thereof (compile on first-time use) (desirable).

  • The framework should check row and column level security and act appropriately (desirable). Additionally, the system should check for rules of governance on the record and ensure that the current system has the authority to update or delete the record.

 

5.2 Types of controls

The edit form could include the following controls:

  • Date control allows a user to enter a date. Other features of a date control include popping up a calendar and allowing the user to navigate the calendar easily. Also, a user should be able to easily select the current date, increase/decrease a day at a time, or increase/decrease by a certain number of days (e.g., +/- 10).

  • Time control allows the user to enter a time value (desirable).

  • Date/time control allows a user to enter a date/time value.

  • Text control allows a user to enter a text value.

  • Note control allows a user to enter a note value. Advanced features of a note control will include the ability to format text, ranging from simple formatting up to sophisticated formatting, such as word processing packages.

  • Radio control allows a user to enter a bit value.

  • Numeric control allows users to enter integers and decimal values. Including a calculator in the control will be desirable.

  • Single pick list allows users to select a value from a list of foreign key values. Features of the single pick list are:

    • Will allow a search value to be entered in the text box where the search results adjust accordingly.

    • Will accommodate cached and non-cached values (for small and large lists).

    • Will filter records flagged as inactive but allow the filter for inactive records to be turned off so that records can be selected.

    • Will filter based on the query date for temporal records.

    • Will return the translation for the foreign key, which must default to the translation stored in the data dictionary. The translation can be overridden on a particular form as required.

    • Should allow the user to pop up the complete maintenance list for the table and perform any permitted action, including adding, editing, deleting, and drilling down related data.

  • Multi pick list allows a user to select multiple values and returns a comma-delimited list of all values selected. The multi-pick will have all the same features as the single pick list, except for allowing multiple values to be selected.

  • Multimedia control allows a user to maintain any type of multimedia (photo, movie, sound clip, etc.).

 

5.3 Defaulting of values

When values are added to a form, the user should have the ability to specify a default value based on the following list:

  • Default the value based on a record currently selected.

  • Default the value based on a value set from the browse list. For example, if the browse list is a list of activities performed by a staff member and the user selects ‘Performed by’, it will default to the staff member in the browse list.

  • Default based on a value specified by the user. The user can specify a default value for any form in this case.

  • Default the value based on a fixed value.

5.4 Validation

The form uses validation rules retrieved from the database. Validation can be performed on the client, server, or both sides — for each field, as it is processed, and for all fields on all tabs when the record is saved.

  • Validation will use multi-lingual messages stored in a message table (desirable).

  • Validation will highlight all fields on all tabs where an issue exists. Likewise, it will provide a list of all errors and warning conditions.

  • Validation rules will apply to both form edits and browse edits.

5.5 Governance

We check governance rules for all records before editing them. The general rule for governance is that if a system creates a record, it can update or delete it, provided that governance has not been granted to another system.

If a user attempts to update a record that the system does not have the governance rights to, the system will warn them. Users can be granted the authority to update a record not governed by the system they use. Transferring governance between systems is in place, so we always know which system owns the gold version of that record.

Two different systems can have update capabilities to the same record at the same time, but for two different temporal ranges that do not overlap.

 

5.6 Concurrent updates

The framework should check for an update to a record since the last time a user opened it for updating. For example, if user A opened a record to update it and User B opened the same record, made updates, and saved it, user A should be warned that a concurrent update had occurred and discard the updates.

 

5.7 Temporal access

The user interface will show a user if multiple temporal versions of a record exist. It will then allow the user to switch between those temporal versions. Also, if the user has the necessary authority, they can insert a new temporal segment anywhere in the temporal range, eliminate a temporal record, or edit any temporal record.  Change history tracks all changes to temporal records.

 

5.8 Hyperlinks (Desirable)

A user should be able to send the hyperlink for a record to another user, and that user, in turn, should be able to click on it and view/edit the record, provided they have the requisite permissions. For example, if a user was sending an email to another user about a member, it would be desirable if they could copy/paste a hyperlink into the email for the member. Then, when the user receives the email, they should be able to click on the hyperlink and have the member form open with the appropriate member record, providing the user is authenticated and has the appropriate privileges.

 

5.9 Pre-/post-processing

The framework should allow for executing pre- and post-processing rules for any form. In the standard post-processing logic, validations for all columns are processed, and the data is saved to the database.

 

5.10 Save/close features (Desirable)

The framework may provide the following advanced features for forms:

  • Add Next, which allows a user to save the current record and open a form for a new record all with one action.

  • Edit Next, which saves and closes the current form and opens the next record in the browse form all with one action.

  • Shortcut keys to perform all actions on the form (Save and Close, Add Next, Edit Next, etc.).

 

6 Searching For data

6.1 Search engine style search (Desirable)

The Search Engine Style Search will allow users to enter a value and return all browse lists where that value was located in both master and detail records. For example, a user can enter ‘ABC Corp’ and see the ABC Corp contact record, contracts with ABC Corp, financial records for ABC Corp, etc. The user can qualify the search by subject categories such as finance or financial journal entries. The user’s sign-in capabilities will limit the search results. Other features of the search capability will be:

  • Qualification of the search based on equals, contained in, begins with, etc.

  • Qualification based on the source of the column to a column in a table (such as contact name).

  • Limiting search results to a specified number of rows.

  • All capabilities of the browse will be available to the user to perform actions (add, edit, delete, drill down, etc.).

 

6.2Tag records (Desirable)

Tag records allow users to tag any record in the system with a # tag value and then search and retrieve records in a similar method to the Search Engine Style Search. Public and private # tag values will be available to users when flagging and searching for values.

 

7.0 Temporal capabilities

7.1 Query date maintenance

The query date controls the temporal data being returned to a user. Authorized users can backdate the temporal date to any previous date. This will cause all temporal data to appear as of that date. It will also cause the automatic temporal capability to set up new temporal records with the default start date as required.

7.2 Temporal resolution

A default temporal resolution is set for a given system but can be overridden on a table-by-table basis. Temporal data is captured based on different time resolutions. For example, the resolution may be a fiscal year in a government setting. It may be to the day for a health and benefits system and to the second in an oil and gas system. If the temporal resolution was a day and the same temporal record was updated twice on the same day, the second update will merely update the existing record and not cause a new record to be created. All changes to temporal records are tracked in the change history.

8.0 Reporting services (Desirable)

The framework will provide a connection to a report development tool. The system should be able to invoke reports from within the menu system based on security privileges. Users should be able to create new reports and embed them in the menu systems for both public and private reports. Report parameters should be stored in the database just as browse form and edit form parameters are stored. The report parameters will tie into the data dictionary for the system.

 

9 Change history

The change history parameters can be modified to change which commands, tables, and columns change history tracks. The user should be able to browse change history from the following perspectives:

  • View the change history for a record (e.g., drill down and see the change history for a particular contact record).

  • View the change history that resulted from a particular menu option.

  • View the change history that resulted from a particular user or their department.

  • View all changes to a particular column and view the associated change history transaction.

10 Workflow processes (Desirable)

The framework should include the ability to design and update workflow processes. Other features the workflow module should support are as follows:

  • Support the creation of workflow processes graphically.

  • Provide actions, decision points, and flow controls (looping) that can be inserted into a workflow process. Select these items from the rules engine.

  • Able to connect any browse or edit forms into the workflow process.

  • Able to work forward and backward through the workflow process.

  • Able to suspend a workflow process, in which case apply no updates to the database.

  • Able to spawn other workflow processes.

  • Presents the user with a list of all workflow processes assigned to complete and provides them with a history of completed and canceled workflow processes.

  • Provides statistics to management for counts and duration times.

 

11 Dashboards  (Desirable)

The user can personalize the dashboard. The requirements of the dashboard are to allow the user to:

  • Add, edit, and delete widgets on their dashboard and size them accordingly.

  • Refresh content as required.

 

12 Soft deletes

The 3D ES framework has capabilities for soft deleting data. A soft delete causes a record to no longer be visible on a selection list, but the record continues to exist to maintain referential integrity. For example, a contact may cease to exist and need to be eliminated from the registry so it will not appear in selection lists throughout the application. We cannot just delete the contact record because child data (such as financial transactions) reference the contact.

 

As such, we set the row status on the contact’s record to ‘d’, which will cause the contact record to no longer appear in any selection lists. However, the contact’s data will still be visible if there are foreign key references to that contact.

 

Soft deletes are also possible with temporal data. Any segment within a temporal series can be soft deleted. That could be the first segment in the series, a middle one, or the last one. Search forms should be able to include soft deleted records if the user chooses to see them. Browse forms should highlight soft deleted records differently than normal ones.

 

13Duplicate detection and merging (Desirable)

One issue to address in 3D ESs is helping users identify if a record already exists before adding a new one. Even with these capabilities, duplicate records get added. Therefore, maintenance capabilities are required to identify potential duplicates and eliminate them. The framework should include the following built-in capabilities to aid in this task:

  • Use information from the data dictionary to change foreign keys from the old to the new record.

  • Use information from the data dictionary to identify potential duplicates.

 

14Offline processing (Desirable)

Offline processing allows tasks to be pushed to the background, so they don’t affect online processing. The framework should support the following requirements for offline processing:

  • Queues and the ability for administrators to create as many queues as required.

  • Job prioritization in the queue.

  • User notification when offline jobs complete.

  • Job cancelation in the queue.

 

15Rules engine (Desirable)

The rules engine maintains rules in the database that connect to entities in the enterprise database. For example, rules exist to aid in adjudicating claims in a Health and Benefits administration system. The rules connect to a health plan in the system so that the rules only execute for that particular health plan. An example of rules in an oil and gas scenario is rules to distribute costs to oil and gas wells based on contract terms. Rules are temporal in that they can change over time and, as such, execute relative to a query date.

The framework should support the following requirements for rules engines:

  • A user-friendly dialect for advanced users to detect conditions and take action.

  • The ability to connect to any object in the database.

  • The ability to capture syntax errors in the error handling system.

 

16Error processing

The framework will provide central error handling. The requirements of the central error handling are:

  • Provide informative messages to the user that they have encountered an error and that their work may not complete as expected.

  • Log the error in a central location.

  • Include escalation capabilities for notifying system staff.

  • Include the ability to clear the error log.

 

17Creating/maintaining automation parameters

The framework will support an entire engine for creating and maintaining new systems. The maintenance engine will have the following capabilities:

  • Maintain the following system parameters and store them in system tables:

    • Commands/menu options

    • Search/browse/edit form parameters

    • Data dictionary

    • Security groups

    • Rules

    • Dashboard widgets

    • Workflow processes

    • Messages

    • Reports

    • User preferences

  • Support multiple languages (desirable).

  • Support governance controls.

  • Support versioning.

  • Automate parameters between systems.

  • Allow custom forms/controls to be created and blended into the system.

  • Allow an organization to brand the look and feel of the application with its own logo, colors, and fonts.

bottom of page