Quick Start: System Administration
This topic lists the main procedures needed to set up a ContractManager system and groups them into categories. The order in which these procedures are listed serve as a rough sequential guideline of how to configure your ContractManager system. Very often, however, you will need to move back and forth among different procedures.
System administration can be concurrent with system useYou can reconfigure the database, add new forms, change settings, and carry out other administration tasks even after users have started working with the system. Any admin changes you make will be reflected on the user side as soon as the user interacts with the system. |
Configure the ContractManager data structure and the Start Page
The starting point for database configuration is ContractManager's sample data structure, which is available when you first open ContractManager. If this data structure works for you, you can use it unchanged and start your ContractManager work right away. All you would need to do is delete the sample records stored in the containers. Alternatively, you could modify the data structure as little or as much as you like, and change the formatting to suit your preference.
The main procedures for configuring the database structure are:
The app's data structure is built up by creating one or more hierarchies of containers (containers are considered to be strongly linked) and by linking non-hierarchically-linked containers to each other with what we call loose links. It is within a container that records relating to that container are stored. For example, a Department container will contain department records, whereas a Company container and a Person container will contain the records of, respectively, companies and persons. In the container hierarchy, the Department container could be a child of the Company container and the parent of the Person container. When entering data for Department records, for example, the user of the app can choose the company (from all the available companies) to which this department belongs.
When you create containers and configure the app's data structure, it will be these kinds of relationships and linkages between database components that you will be setting up. As a result, the data structure will provide a network of relationships that enables related data to be listed and reported. For more information about containers and data structure, see the following sections: How the App's Data Is Structured, How Data Is Stored, Configuring Database Structure, Databases, and Containers.
|
Within each container, configure the fields that will define records of the container. For example, a Person container (in which Person records are stored) can be defined to have fields such as: FirstName, LastName, Email. You can specify various aspects of each field, such as datatype or an entry list from which the user can choose a value. You can also configure validation rules for individual fields and for records as a whole; this would warn users about possible errors in data entry. See the section Fields for details.
|
Forms are what the user will interact with. These are of the following types: list forms, data entry forms, report forms, export forms, and email forms (for email reminders). Each container has its own set of different forms. So whenever records from a container are displayed, they will be displayed in an appropriate form. One major advantage of using container-based forms is that access to each type of form can be set separately. As a result, you can design some forms to show data that only some users are authorized to see and/or edit. You can also design other forms that do not show certain data. Reports of the data in a container are presented by using a report form of that container. Similarly, other types of forms are used for other types of presentations. The various types of forms are described in the section Forms.
|
One or more filters can be defined on each container. A filter restricts the display of records in a container on the basis of some criterion (or criteria) relevant to that container. For example, for a Contracts container, you could create a filter that shows only contracts that expire in the current year. Such a filter would be built, for example, by checking the ExpiryDate field of records in the container. After a filter has been created, it can be used during configuration as well as data entry, for example, to restrict lists. See the section Filters for information.
|
When users log in to the system to either enter data or retrieve information, they see a Start Page, which is their entry point into the system. Essentially, the Start Page provides access to the various containers of the system. The Overview Form is what an administrator uses to design this Start Page. See the section Overview Form for information about designing the Start Page.
|
Set up system users and their roles
These procedures determine who will use the ContractManager system and in what capacity. You should check whether the roles that are defined in the sample dataset suit your requirements. For the beginning, it might be best to use just the two predefined roles, Admin and All Users. After you become familiar with your data and its structure, the system, and your users, you can develop roles to suit your requirements.
Besides specifying which users can log in to the ContractManager app and their respective login credentials, you must also define what access rights each user has and the role/s each will play. For example, does a user in the IT Department have access to only technology contracts, or legal contracts as well; or, is a certain user allowed to have an administrator role, which entails access to the app's configuration settings? These access rights are determined by the roles (see next step) given to each user. See the sections Users and Roles for details.
|
Create different roles according to your organization's needs. For each role, define (i) the containers to which access is allowed, and (ii) the forms to which access is allowed and, where necessary, the type of access allowed (for example, read/write or read only), (iii) the reports to which access is allowed, (iv) whether export of data is allowed. After roles have been created, give one or more of these roles to each user (see previous step). See the sections Users and Roles for detailed information.
|
Global settings and reminder mails
At an early stage in the development process, you should have a look at what global settings are available and consider how you can best use them. Reminder emails are probably best left to the end of the configuration process, but it would be useful to at least quickly look through the documentation abut reminders in order to see what is involved.
The Settings page provides a number of styling, content-formatting, print formatting, and other settings that can be set for the entire app. We recommend that you go to this page and see what settings are available and how you can use them. The Image Library setting and Reminder Email settings should be noted. Also note that, when you configure certain items, such as forms, you can specify local settings and override the global settings that are defined on the Settings page. You can define global settings at any time: before database configuration, after database configuration, and even after system use has started.
|
In systems like a contract management system, it is important to take certain actions before specific dates (say, a contract renewal action before the contract expiry date). The system can automatically send reminder emails to the appropriate person or persons a given number of days before such key dates. See the section Reminder Mails for information about how to set this up.
|