Demystifying View Forms in BMC Remedy AR System: A Deep Dive for Professionals

In the complex landscape of BMC Remedy AR System (now BMC Helix ITSM), understanding the nuances of form types is paramount for effective system design, administration, and development. Among these, View Forms play a crucial role in presenting data intelligently and efficiently. They aren’t just another form; they are a strategic tool for consolidating, filtering, and displaying information derived from other sources. This article aims to provide a comprehensive, human-like technical exploration of View Forms, delving into their purpose, structure, common complications, and best practices, all while keeping you informed and interview-ready.

For anyone working with Remedy AR System, whether you’re a seasoned administrator, a developer crafting custom applications, or even a business analyst trying to understand data flows, grasping the concept of View Forms is a significant step towards mastering the platform. We’ll break down what makes them tick, how they interact with other forms, and what pitfalls to watch out for.

Understanding the Core: What Exactly is a View Form?

At its heart, a View Form is a special type of form in BMC Remedy AR System designed to present data that doesn’t reside directly within its own database tables. Instead, it acts as a sophisticated window, pulling and often transforming data from one or more underlying forms. Think of it as a curated exhibit; you’re not looking at the raw materials, but rather a polished presentation of them.

The primary purpose of a View Form is to:

• Consolidate Information: Bring together data points from disparate forms into a single, coherent view. This is incredibly useful for creating dashboards or summary screens.
• Filter and Refine Data: Present only the relevant subset of data based on specific criteria, making it easier for users to find what they need.
• Abstract Data Complexity: Shield end-users from the underlying complexity of how data is stored across multiple forms.
• Improve Performance: In some scenarios, a well-designed View Form can offer better performance for data retrieval by avoiding joins at the user interface level.

View Forms vs. Other Form Types: A Crucial Distinction

To truly appreciate View Forms, it’s essential to understand how they differ from other form classifications within Remedy AR System. This distinction is not just academic; it has practical implications for development and troubleshooting.

The reference material provides a helpful list of form IDs and types. Let’s elaborate:

• Regular Form (ID: 1): This is your standard, everyday form. It has its own dedicated database tables (T, B, H) and stores data directly. When you create a new form in Remedy, you’re usually creating a Regular Form.
• Display Form (ID: 4): A Display Form is essentially a read-only version of a Regular Form. It doesn’t have its own database tables and primarily serves to present data from another form in a read-only mode. It’s a way to control presentation without allowing modifications.
• Join Form (ID: 2): Join Forms are powerful. They combine data from two or more other forms based on specified join criteria. Think of it as merging columns from different tables into one view. BMC’s recommendation to join up to 6 forms is a practical guideline to maintain performance and manageability.
• View Form (ID: 3): This is our focus. A View Form presents data from *other* forms. It doesn’t typically have its own primary data tables. Instead, its fields are mapped to fields in the source forms. This is where its power of consolidation and presentation truly shines.
• Vendor Form (ID: 5): These are special forms that allow Remedy to interact with external data sources. The “Server Information” form is a classic example, extracting data from text files. They act as a bridge, enabling Remedy to query and display data that isn’t natively stored within the AR System database.

The key takeaway here is that a View Form is *not* the source of the data; it’s a window onto that data. This is a fundamental concept that will guide your understanding of its behavior.

The Mechanics of a View Form: Under the Hood

When you save a new form in BMC Remedy AR System, the system typically creates three corresponding tables in the underlying database: T (Transaction), B (Binary), and H (History). This is true for Regular Forms.

However, for View Forms, the scenario is different. Because a View Form doesn’t store its *own* primary data, it doesn’t get its own primary T table. Its fields are essentially pointers or mappings to fields in the source forms.

The Role of View Fields

The magic behind a View Form lies in its fields, specifically what are often referred to as “View Fields.” When you define a field on a View Form, you are telling Remedy where to find the corresponding data in its source. This mapping is critical.

Imagine you have an “Incident” form and a “Customer” form. You want to create a View Form that shows the Incident Summary, its Status, and the Customer’s Name. On your View Form, you would add fields for “Summary,” “Status,” and “Customer Name.” When configuring these fields on the View Form, you would map them to the corresponding fields on the Incident form (for Summary and Status) and potentially the Customer form (for Customer Name), possibly through a Join Form that links Incident to Customer.

Real-World Example: A common use case is creating a “My Open Incidents” View Form for support staff. This View Form would pull data from the main Incident form, but it would filter it to show only incidents assigned to the logged-in user and those with an “Open” status. The fields on the View Form would be mapped to the appropriate fields on the Incident form (e.g., ‘Assigned To’, ‘Status’, ‘Summary’, ‘Incident ID’).

Form View (Creating User-Specific Views)

The reference mentions “Form View (create a view of form for different users).” This concept is closely related to, but distinct from, View Forms. A “Form View” often refers to how a specific form is presented to different users or groups. This can be achieved through various means:

• Permissions: Restricting access to specific fields or even entire forms based on user roles.
• Active Links/Filters: Dynamically showing or hiding fields, or changing their properties, based on user context.
• UI Components: Leveraging different UI elements or configurations.

While a View Form *can* be used to create a specific view for users (e.g., a simplified view), the term “Form View” is broader and encompasses presentation and access controls beyond just data sourcing.

Form Creation and Database Tables: What You See and What You Get

As mentioned, when you save a Regular Form, you get three database tables: T, B, and H.

• T – Transaction Table: This is the primary data storage for the form. Every record you create in a Regular Form gets an entry here. It holds most of the form’s data fields.
• B – Binary Table: This table is essential for storing attachments (like documents or images) associated with form records. It also stores active links, workflow objects associated with the form.
• H – History Table: This table is crucial for audit trails and history tracking. When a record is modified, its previous state might be logged here, depending on the form’s configuration. This is vital for compliance and troubleshooting.

For a View Form, the database table situation is typically different. Since it doesn’t store its own primary data, it doesn’t get its own dedicated T table. Its fields are mapped to the fields of the source form(s), which *do* have their own T, B, and H tables. The View Form’s definition itself is stored in the AR System’s metastructure tables.

Handling the Request ID Field: Customization and Control

The Request ID field is the unique identifier for each record in a form. It’s a critical piece of data, and administrators often need to customize its appearance and behavior.

Adding a Prefix to the Request ID

To give your Request ID a more meaningful or structured prefix (e.g., “INC0000012345”), you can leverage the “Default Value” property of the Request ID field. Simply go to the field properties, navigate to the “General” tab (or equivalent depending on the AR System version), and enter your desired prefix in the “Default Value” field. For instance, if you want all incident IDs to start with “INC-“, you’d enter “INC-” there. The system will then automatically append the sequentially generated number to this prefix.

Restricting Input Length of the Request ID

While the Request ID is typically system-generated and not manually input, there might be scenarios where you need to control its potential length, especially if it’s part of a larger composite key or for UI display limitations. To restrict the input length of the Request ID field, you would typically go to its properties, then navigate to the “Database” tab and set the “Input Length” property. Be cautious with this setting, as it can impact system-generated IDs if set too restrictively. It’s generally recommended to let the system manage the Request ID’s length to avoid unexpected issues.

Join Forms: The Power of Merging Data

Join Forms are indispensable for creating comprehensive views by combining data from multiple sources. As mentioned, BMC recommends joining up to 6 forms. This guideline is based on performance considerations; as the number of joins increases, the complexity of the query and thus the potential for performance degradation also rises.

Changing Join Criteria in Version 8.1 and Beyond

A critical point for administrators and developers working with older versions of AR System (specifically, before version 8.1) to note is that once a join criteria is defined in a Join Form, you cannot change it. This means if you need to modify how the forms are joined, you would have to delete the existing Join Form and recreate it with the correct criteria. This constraint was addressed in later versions, offering more flexibility.

Creating Join Forms from Various Sources

The flexibility of Join Forms extends to the types of forms they can incorporate. You can create a Join Form by joining:

• Regular Forms
• View Forms
• Vendor Forms
• Archive Forms
• Audit Forms

This interoperability allows for intricate data architectures, enabling you to build powerful reporting and analytical tools by merging data from various operational, historical, and external sources.

Help Text Display: Guiding Your Users

The way help text is displayed for fields can vary based on the user’s login. This is an important consideration for user experience and training.

• Login by Demo User: When logged in as the ‘Demo’ user (often used for demonstrations and initial setup), you get a more verbose display of field information. This typically includes the Field Name (label Name), the Field ID, and the Help Text value. This is very useful during development and testing to quickly identify fields and their associated help documentation.
• Login by Other User: For regular end-users, the display is streamlined. They will only see the Help Text value. If no help text is configured for a field, they will see descriptive symbols representing the field’s properties, such as its keyword or length. This encourages administrators to provide clear and concise help text for all fields to enhance user understanding and reduce support queries.

Practical Tip: Always test your forms and fields with both a ‘Demo’ user account and a regular user account to ensure the help text is displayed as intended and is helpful in both contexts.

Granular Overlays: The Art of Selective Customization

In modern AR System development, managing customizations is key to smooth upgrades and patch deployments. Granular Overlays are a sophisticated mechanism that allows developers to customize specific subcomponents of an object (like a form or a field) rather than the entire object. This is a significant improvement over traditional overlays, as it minimizes the potential for conflicts during upgrades.

Granular overlays work by inheriting aspects from the origin object (the original BMC-provided object) unless specifically overridden. This means that during an upgrade, only the parts you’ve explicitly changed through overlays are considered. BMC’s aim is to make upgrades less painful and more predictable.

There are three main types of granular overlay configurations:

• Additive Overlay (Extensions Overlay): This is used to add new functionality or information to an origin object. Think of it as adding extra shelves to a pre-built cabinet. Any additions made via an Additive Overlay are typically appended during upgrades. This is the preferred method for most customizations.
• Overwrite Overlay: This type of overlay replaces the entire overlaid object with your custom version. The origin object’s corresponding part is effectively ignored. This is akin to swapping out an entire shelf in the cabinet with your own custom-designed one. It’s useful for scenarios where you need to fundamentally change the behavior or properties of a component, such as removing specific permissions that are applied by default. However, use this with caution, as it can lead to larger merge conflicts if not managed carefully.
• No Overlay (Inheritance Overlay): This is the default setting for most object parts when you create a granular overlay. If a property is set to “No Overlay,” it means that the object part will inherit its properties directly from the origin object during upgrades. This is the default and recommended approach for properties you don’t intend to modify. It ensures that all default behaviors and configurations from BMC are maintained unless you explicitly choose to override them.

Why this matters for View Forms and other objects: When customizing a View Form, or any other AR System object, understanding granular overlays is crucial. You can apply granular overlays to forms, fields, active links, filters, and more. By judiciously using additive and no-overlay settings, you create a more robust and upgrade-friendly customization strategy.

Form Deletion and Associated Workflow: A Delicate Balance

When you decide to delete a form from your AR System environment, it’s important to be aware of the implications for associated workflow objects.

The reference states: “When a form is deleted, associated active links are also deleted, provided they are associated with that specific form.” This is a critical piece of information.

• Direct Association: If an active link (or filter, escalation, etc.) is directly created or configured to trigger *only* on that specific form, then deleting the form will indeed lead to the deletion of that active link.
• Indirect Association: However, if an active link is configured to act on multiple forms, or if it’s triggered by an event on another form that *might* involve the form you’re deleting, its deletion might not be automatic.

Troubleshooting Tip: Before deleting any form, it’s a best practice to perform an impact analysis. Use the AR System’s built-in tools to search for all workflow objects (active links, filters, escalations, etc.) that are associated with or might be affected by the form you intend to delete. This proactive step can save you significant troubleshooting time later.

Troubleshooting Common View Form Issues

View Forms, while powerful, can sometimes present unique challenges. Here are a few common issues and how to approach them:

1. Data Not Displaying Correctly in a View Form

Symptom: A View Form is blank, shows incorrect data, or is missing expected fields.

• Check Field Mappings: The most common culprit. Go into the View Form’s definition and meticulously verify that each field is correctly mapped to its source field in the underlying form or Join Form. Ensure data types are compatible.
• Verify Source Form Data: Is there actually data in the source form(s) that the View Form is trying to display? Query the source forms directly to confirm.
• Join Criteria: If the View Form is based on a Join Form, ensure the join criteria are correct and that there are matching records in all joined forms. Try querying the underlying Join Form directly.
• Active Links/Filters on Source Forms: Sometimes, workflow on the source forms might be inadvertently filtering or modifying data in a way that prevents it from appearing on the View Form.
• Permissions: Does the user viewing the form have the necessary permissions to see the data on the source forms?

2. Performance Issues with View Forms

Symptom: View Forms are slow to load or query.

• Complex Joins: If your View Form relies on multiple complex joins, especially through an intermediary Join Form, performance can suffer. Review the join structure and simplify if possible.
• Large Data Sets: If the source forms contain a vast amount of data, querying and filtering can become slow. Ensure efficient use of indexes on the source forms.
• Workflow on View Form: While View Forms are designed to present data, if you have computationally intensive active links or filters running *on* the View Form itself, this can impact performance.
• Vendor Form Performance: If your View Form pulls data from a Vendor Form, the performance of the external data source and the connector will directly impact your View Form.

3. “Cannot Find Form” or “Invalid Form” Errors

Symptom: Users receive errors when trying to access a View Form.

• Form Deletion: Was the underlying form(s) or the View Form itself deleted without proper handling of its associations?
• Deployment Issues: If the form was recently deployed or migrated, ensure it was done correctly and all dependent objects were moved.
• Metadatalock: Check if the form is locked by another process or user.

Interview Relevance: How to Ace Those View Form Questions

Understanding View Forms is a sign of a competent Remedy AR System professional. Here’s how to prepare for interview questions:

• Define a View Form: Be ready to explain it in your own words, emphasizing its role in presenting data from other sources. Contrast it with Regular and Join forms.
• Use Cases for View Forms: Provide practical examples, like creating dashboards, user-specific incident lists, or consolidated reporting screens.
• How are View Forms built? Discuss field mapping and the absence of primary database tables for the View Form itself.
• What are the advantages of using View Forms? Focus on data consolidation, abstraction of complexity, and potential performance benefits.
• What are potential downsides or challenges? Mention complexity in setup, troubleshooting mapping issues, and performance considerations with complex joins or large datasets.
• Explain Granular Overlays and their relevance to customizing forms, including View Forms. This demonstrates an understanding of modern customization best practices.
• Discuss the implications of deleting a form on associated workflow. This shows awareness of system integrity.
• What is a Join Form, and how does it relate to View Forms? Understand that a View Form might be built upon a Join Form.

Interview Tip: Don’t just recite definitions. Weave in your practical experience and provide concrete examples. If you’ve ever encountered a problem with a View Form, explain how you solved it. This demonstrates problem-solving skills.

Conclusion

View Forms are more than just a technical classification in BMC Remedy AR System; they are a strategic tool for designing user-friendly, data-rich applications. By understanding their role in consolidating, filtering, and presenting information from underlying forms, administrators and developers can build more efficient and elegant solutions.

From the intricacies of field mapping to the strategic use of Join Forms and the modern approach of Granular Overlays, mastering View Forms is a testament to your depth of knowledge on the platform. Remember to always consider the user experience, performance implications, and the impact of your customizations. With this comprehensive understanding, you’re well-equipped to leverage View Forms effectively and confidently tackle any related challenges.