Data management

In FootPrints, data is stored and managed in containers. Each container holds specific types of data records. The following container types are supported:

Address books
CMDBs
Knowledge bases
Service portfolios
Workspaces

Each type of record is configured in an item definition. Contact items are stored in address books, ticket, survey and asset items in workspaces, and so on. You can create variations of most item types, naming and configuring them to suit your business needs. However, you can only manage ticket-type data in ticket items, contact-type data in contact items, and so on.

For example, if you categorize incoming requests according to their criticality, you might create ticket items named Incident, Problem, Change Request, and so on. Each item could be configured to contain certain types of information and tasks, be assigned to different users and teams, and be acted on by different business rules. Because record numbering is managed at the item level, each record is identified uniquely by the combination of record ID, item ID and container ID.

This topic provides information about:

Linking

You can create relationships between items in the same container or items in one container to corresponding items in another container. For example, you might link a workspace to an address book, knowledge base, CMDB, and service portfolio.

One way to take advantage of the relationship feature is to distribute your items across multiple workspaces and link the workspaces together. For example, you might store initial incoming requests in one workspace and the resulting change requests in another workspace.

Customizing fields

Data content, processing and access can be configured at a field level as well. The built-in fields can be configured and new fields can be created as needed. If multiple items in a container will use some of the same fields (such as Department ID fields or financial coding fields), you can create those fields at the container level and then add them as needed to the items in that container. You can also configure groups of fields that work together and impose greater control on both the content of incoming tickets and how they are processed. For example, you could add a selection tree in a service portfolio that guides the user from IT Services to a choice of Hardware, Software, and Services, and from there to more specific options.

Record ID numbers can be customized with prefixes and starting values that you define. The name of the record ID field varies by container. For example, the field would be named Ticket Number by default but you could rename the field to Incident ID or another name to better identify it for your working environment. For more information, see Customizing ticket numbers and other record IDs.

Note

BMC recommends that you do not add more than 100 fields on a single form. If you add more than 100 fields, it might impact the application performance.

Automation

Business rules and workflow processes can be created and configured to manage the progress of records from creation through closure. Business rules can be configured to change field values, copy or move records to other containers, send notifications, and close resolved tickets. Workflow processes provide automated actions to control approvals and escalations.

Implementation

The configuration settings for each container are saved in draft mode while you are working on them. They stay in draft mode until you publish the container. Publishing implements the settings. However, until you assign roles and users to the published container, only System Administrators and the container's Administrators can see the container or its data.

Once you have configured the necessary containers and items, you can create or import the data for each. By designating the container and role for each user, you can import users and set basic user permissions at the same time.

User security

User permissions are configured in several ways, allowing you to permit very few users to access certain data (such as requests for financial approval) or to permit all users of a certain group to access the data. Customers have limited permissions that range from read-only to submitting and editing their own tickets. Access to each container and item can be configured so that only the appropriate users see and edit the data. You can show and hide containers, items, and fields. Users who are not authorized to access an object will never see it.

For more information, see the Related topics.

Accessing data through external tools for reporting and analytics purposes

BI tools often create huge demands on the database engine, which can cause performance problems in FootPrints that are difficult to diagnose. Since the reporting engine creates occasional big hits on the database, it can often be difficult recognizing that FootPrints performance issues are being caused by the BI tool.

As such, BMC strongly recommends that customers use their standard database tools to regularly move/replicate the data to another server and then run the BI tools against that separate database/server. In addition, customers should note that there is no breach of license for reading FootPrints data out of the FootPrints database.

Replicating data to a separate server is just as important for Data Warehouse uses as this offloads not just the reporting but the data transformation loads from the production FootPrints Server.