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
- Knowledge bases
- Service portfolios
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:
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.
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.
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.
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.
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 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.