Demystifying BMC Remedy AR System Form Types: A Deep Dive for Professionals

In the realm of IT Service Management (ITSM) and enterprise application development, data representation is king. BMC Remedy AR System, a robust platform for building and managing enterprise applications, relies heavily on its sophisticated form design capabilities. Forms in AR System aren’t just simple interfaces for data entry; they are the very schema by which your business data is structured, stored, and interacted with. Understanding the different types of forms is crucial for any developer, administrator, or even advanced user looking to leverage the full power of AR System.

This article aims to provide a comprehensive and human-like explanation of the various form types available in BMC Remedy AR System. We’ll go beyond simple definitions, exploring their practical applications, nuances, and how they fit into the broader AR System architecture. Whether you’re troubleshooting a complex integration, designing a new application, or preparing for an interview, this guide will equip you with the knowledge you need.

The Foundation: Forms as Data Schemas

At its core, a Form in BMC Remedy AR System serves as a blueprint for how data is organized, much like a table in a relational database. Each form represents a specific type of data entity (e.g., an Incident, a Change Request, a User). Fields within a form correspond to the columns in that database table, holding specific pieces of information for each record.

The beauty of AR System lies in its ability to abstract the underlying database. While forms map to database tables (often with a T prefix for the table name in the AR System database, followed by the form ID), you interact with them through a rich, customizable user interface. This abstraction allows for greater flexibility and simplifies application development.

The AR System ecosystem is built upon several core components, and forms are undoubtedly one of the most fundamental. Other key components that work in tandem with forms include:

• Menus: Provide predefined lists of options for fields, ensuring data consistency.
• Workflow: The intelligence behind the forms, encompassing active links, filters, and escalations that automate processes and define business logic.
• Active Links: Event-driven workflow that responds to user actions or system events in real-time.
• Filters: Workflow that triggers based on data changes or other events, often used for server-side processing.
• Escalations: Workflow that runs on a schedule, perfect for time-sensitive tasks like overdue ticket notifications.

Understanding Form IDs and Their Significance

Before diving into the specific form types, it’s important to acknowledge that each form in AR System is assigned a unique identifier, known as a Form ID. These IDs are numerical and are generated by the system. While you typically work with form names, these IDs are crucial for internal system operations and certain advanced configurations or troubleshooting scenarios. The reference provides us with a mapping for some of these:

• Regular Form: ID = 1
• Join Form: ID = 2
• View Form: ID = 3
• Display Form: ID = 4
• Vendor Form: ID = 5

These IDs are not arbitrary. They signify the fundamental nature and purpose of the form within the AR System architecture, influencing how it interacts with other components and the data it can represent.

Exploring the Core Form Types

BMC Remedy AR System offers several distinct types of forms, each designed to fulfill specific requirements. Let’s break them down:

1. Regular Forms

Form ID: 1

Regular forms are the workhorses of AR System. They are the most common type and represent a single, standalone table in the AR System database. Think of them as the foundational building blocks for most data entities in your applications. When you need to store and manage a distinct set of data, like employee details, hardware assets, or software licenses, you’ll typically start with a regular form.

Practical Applications:

• Storing core business objects (e.g., a form for “Customers”).
• Managing master data (e.g., a “Product Catalog” form).
• Capturing transactional data (e.g., a “Service Request” form).

Key Characteristics:

• Directly maps to a single database table.
• Can be the source or target of data for other forms.
• Supports all AR System workflow and automation capabilities.

Real-World Example: Imagine an IT department using AR System. A “Hardware Assets” form would be a regular form. It would have fields like “Asset ID,” “Serial Number,” “Model,” “Manufacturer,” “Purchase Date,” and “Assigned To.” Each record in this form represents a single piece of hardware.

2. Join Forms

Form ID: 2

Join forms are powerful tools that allow you to combine data from two or more existing forms into a single, unified view, without physically merging the data into a new table. They achieve this by defining join criteria between specific fields of the constituent forms. This is incredibly useful when you need to present related information from different data sources in a cohesive manner, especially for reporting or user interaction.

Practical Applications:

• Displaying incident details along with the associated problem record.
• Showing user information alongside their assigned tickets.
• Reporting on change requests and their related release records.

Key Characteristics:

• Combines data from two or more source forms (can be Regular, View, Vendor, Archive, Audit, or even other Join forms).
• Join criteria (e.g., `FormA.FieldX = FormB.FieldY`) are established to link records.
• The primary form (the “left” side of the join) dictates the records displayed. If no match is found in the secondary form, corresponding fields remain blank.
• Important Note from Reference: The reference mentions a critical point for Join Forms: “you can’t change the join criteria once you define. It is a bug of 8.1 dev.” While this might have been a specific observation in older versions, it’s always good practice to carefully define join criteria during initial development. If modifications are indeed required, it might involve recreating the join form or carefully working around limitations, which can be complex. Always test modifications thoroughly.
• You can create a join form of other forms these are: join, view vendor, regular, archive, audit also. This highlights the flexibility in combining different types of data sources.

Real-World Example: Consider a scenario where you want to see a list of all open Incidents, and for each incident, you also want to display the name of the person who reported it. You might have a “HPD:Help Desk” (regular form for incidents) and a “User” (regular form for users). A join form could combine these two, linking the “Reported By” field in “HPD:Help Desk” to the “Login ID” in the “User” form. The resulting join form would show incident details alongside the reporter’s name.

3. View Forms

Form ID: 3

View forms are designed to present a logical “view” of data from one or more underlying forms. They don’t store their own data but rather act as a dynamic facade, aggregating or filtering data from other sources. This is particularly useful for creating customized dashboards, reports, or specific user interfaces that require a tailored perspective on the data without duplicating it.

Practical Applications:

• Creating a summary dashboard of critical incidents.
• Generating reports that combine data from different forms in a specific way.
• Providing different user groups with a filtered or specialized view of the same data.

Key Characteristics:

• Does not have its own database table.
• Data is derived from one or more source forms (Regular, Join, View, Vendor, Archive, Audit).
• The reference mentions “View Field” and “Form View.” A “View Field” likely refers to a field within a view form that pulls data from an underlying form. “Form View” is described as “create a view of form for different users,” which aligns perfectly with the purpose of View Forms – to tailor data presentation.
• Can act as a source for other forms, including Join forms.

Real-World Example: A manager might want to see only high-priority incidents that are currently open and assigned to their team. A View Form could be created that queries the “HPD:Help Desk” form, applying filters for priority, status, and assigned group. This View Form would present only the relevant incidents to the manager.

4. Vendor Forms

Form ID: 5

Vendor forms are a powerful mechanism that allows BMC Remedy AR System to interact with external data sources that are not directly managed by AR System itself. They act as bridges, enabling AR System to “see” and even manipulate data residing in databases, flat files, or other applications that are not part of the AR System repository.

Practical Applications:

• Integrating with legacy systems that hold critical business data.
• Accessing data from external HR or finance systems.
• Reading configuration information from flat files (as noted in the reference: “Form Type of Server Information: vendor. Because it extracts data from text file.”).

Key Characteristics:

• Leverages BMC Remedy AR System’s Vendor functionality.
• Requires a Vendor form definition in AR System and a corresponding Vendor tool (a piece of software that knows how to connect to the external data source).
• Data appears within AR System as if it were native, but it’s actually being fetched or updated in real-time from the external source.
• Important Note: The reference states: “forms allow BMC Remedy AR System to access arbitrary external data sources through the use of a BMC.” This emphasizes their role as conduits to diverse external data.

Real-World Example: Suppose your organization uses a separate system for managing employee contact information that isn’t integrated into AR System. You could create a Vendor Form that points to this external system. Then, within your AR System application, you could display and potentially update this contact information without needing to migrate it to AR System’s database. This is extremely useful for “read-only” scenarios or simple data retrieval.

5. Display Forms

Form ID: 4

Display forms are a specialized type of form that doesn’t store data itself. Instead, they act as containers for displaying data that is pulled from other forms. They are typically used in conjunction with workflow (like Active Links or Filters) to present information to the user in a particular context, often in a read-only fashion or for guiding the user through a process.

Practical Applications:

• Presenting detailed information about a selected item from a list.
• Creating pop-up windows or dialogs for user confirmation or information display.
• Guiding users through multi-step processes by displaying relevant context.

Key Characteristics:

• Does not have its own database table.
• Data is sourced from other forms using workflow.
• Often used for transient information display or user guidance.

Real-World Example: When a user clicks on an incident in a search result, a Display Form might pop up showing all the details of that specific incident. The data displayed on this pop-up form would be fetched from the corresponding record in the “HPD:Help Desk” Regular Form via workflow.

Advanced Concepts and Considerations

Form Views and User Personalization

Beyond the fundamental form types, AR System allows for the creation of multiple “Views” within a single form. A View is essentially a different layout or presentation of the same underlying form data. This is what the reference implies with: “Form View——->create a view of form for different users.”

Practical Applications:

• Role-Based Interfaces: Provide a simplified view for end-users and a more detailed view for IT administrators, all using the same underlying form.
• Contextual Display: Show different fields or sections of a form based on the current status or type of request.
• Personalization: Allow users to customize their own view of a form (within defined limits).

This feature is powerful for creating a user-friendly and efficient experience, ensuring that users see only the information and fields relevant to their role and task.

Workflow and Form Deletion

A common question that arises during system maintenance and development is the impact of deleting forms. The reference touches upon this: “Q. when form will delete , whether active link delete or not. Yes, but when you will delete all forms which active link is associated.”

This statement needs clarification. If you delete a form that is referenced by workflow (e.g., an Active Link that targets a form for an action), the workflow itself will likely become invalid and may generate errors when it attempts to execute. In many cases, AR System might prompt you to remove associated workflow or the workflow might simply break.

However, the statement “Yes, but when you will delete all forms which active link is associated” is a bit misleading. You don’t typically delete the active link because the form is deleted. Rather, the active link (or other workflow) that *targets* the deleted form will cease to function. If you intend to delete a form and its associated workflow cleanly, you should first identify and disable or delete the workflow components that reference it. AR System’s data integrity checks can sometimes help prevent deleting forms with active dependencies, or at least warn you.

Troubleshooting Tip: If you encounter unexpected behavior after deleting a form, check any workflow (Active Links, Filters, Escalations) that previously targeted that form. You might need to reconfigure or remove those workflow objects.

Installation Steps and Application Components

While the article focuses on form types, it’s important to remember that forms are part of a larger application structure. The reference briefly mentions “Installation steps” and “What are application components of ARSystem?”.

Application Components of ARSystem:

• Form: The data schema.
• Menu: For pick lists and selections.
• Workflow: The business logic (Active Links, Filters, Escalations).
• Active Link: Client-side, real-time automation.
• Filter: Server-side automation, triggered by data changes.
• Escalation: Scheduled automation.

Understanding how these components interrelate is key to building robust AR System applications. Forms provide the structure, and workflow brings them to life.

Interview Relevance

For anyone interviewing for a role as a BMC Remedy Administrator, Developer, or ITSM Consultant, a solid understanding of form types is non-negotiable. Be prepared to:

• Explain the purpose and use cases of each form type.
• Differentiate between Regular, Join, View, Vendor, and Display forms.
• Provide real-world examples of where each form type would be most effective.
• Discuss the implications of join criteria in Join Forms, especially regarding potential issues in older versions.
• Explain how View Forms contribute to user personalization and role-based interfaces.
• Articulate the role of Vendor Forms in integrating with external data sources.
• Understand the relationship between forms and workflow, particularly concerning deletion and dependencies.

Troubleshooting Common Form-Related Issues

Even with the best design, form-related issues can crop up. Here are a few common scenarios and how to approach them:

Conclusion

Forms are the bedrock of BMC Remedy AR System applications, providing the structure and interface for all your data. By understanding the distinct characteristics and capabilities of Regular, Join, View, Vendor, and Display forms, you unlock the potential to build highly functional, efficient, and integrated ITSM solutions. Whether you’re a seasoned professional or just starting your journey with AR System, a deep appreciation for these form types will undoubtedly enhance your ability to design, manage, and troubleshoot.

Remember that the power of AR System lies in the synergy between its components. Forms, menus, and workflow work in harmony to deliver sophisticated business processes. Mastering form types is a crucial step in mastering the entire platform.