Push Fields Mapping

In the world of IT Service Management (ITSM) and enterprise software, efficiency and automation are paramount. When you’re dealing with complex systems that manage vast amounts of data – think customer support tickets, asset inventories, or project tasks – the ability to move information seamlessly between different parts of the system can be a game-changer. This is where the Push Fields action, a powerful tool in platforms like BMC Helix ITSM (formerly BMC Remedy), truly shines.

At its core, Push Fields mapping is all about automating data transfer. It allows you to take information from one record (or request) and intelligently send it to another. This might sound simple, but the implications for streamlining workflows, reducing manual data entry errors, and keeping your data consistent across your organization are enormous. Let’s dive deep into what Push Fields mapping entails, how it works, and why it’s such a critical concept for anyone working with these systems.

What is Push Fields Mapping?

Imagine you’re working in a system that tracks IT incidents. When a user reports a problem (an incident request), you might need to gather certain details. If that incident escalates into a change request, or if it requires an asset to be updated, you don’t want to re-enter all the information manually. This is precisely where Push Fields mapping comes in.

The Push Fields action, as mentioned, is a core feature used within various automation contexts like:

• Active Links: These are typically used to automate actions based on user interactions within a form, often in real-time.
• Filters: Filters are triggered by specific events or data changes within the system, often when a record is saved or modified.
• Escalations: Escalations are time-based or event-driven processes that automate actions when certain conditions are met over time.

Through these mechanisms, Push Fields allows you to:

• Transfer Values: Move data from selected fields in the current request to another request.
• Target Flexibility: This “another request” can be in a different form within the same application or even in the same form, perhaps to update related records.
• Update or Create: Push Fields can be configured to either update existing records that match certain criteria or to create entirely new records if none are found.

The Power of Data Transfer

The ability to push values from virtually any field type is what makes Push Fields so versatile. This includes:

• Standard Data Fields: Text, numbers, dates, checkboxes, radio buttons, etc.
• Table Fields: While you can’t push *to* a table field itself (it’s a container), you can push data from individual columns within a table on the source form to fields on the destination form.
• Hidden Fields: Data that isn’t visible to the user but is crucial for backend processing can be pushed.
• Fields Not in the Active View: Even if a field isn’t currently displayed on the user’s screen, its value can still be pushed.
• Fields in No Views at All: This is a powerful capability for data that might be stored purely for backend logic or auditing.

However, there are limitations. You cannot push values to certain non-data fields that are essentially UI elements or containers, such as:

• Table Fields (as a whole): You can’t push a whole table of data into a single “table field” destination.
• Column Fields: These are part of a table’s structure.
• Panel Holders: These are layout elements for organizing fields on a form.

A key constraint to remember is that each Push Fields action can push data from the current form to one other form. This means if you need to update records in multiple different forms, you’ll need to configure multiple Push Fields actions, each targeting a specific destination form.

Practical Applications and Real-World Examples

Let’s ground this concept with some practical scenarios where Push Fields mapping is a lifesaver.

Example 1: Incident to Change Request Automation

Scenario: A critical incident is reported that requires a system outage and therefore a change request to be created and approved.

How Push Fields Helps:

• When an incident is categorized and has a severity that meets the criteria for a change request (e.g., “Critical Incident impacting production”), an Active Link or Filter can trigger a Push Fields action.
• Source Form: Incident Management
• Destination Form: Change Request
• Fields to Push:
  • Incident Summary (from Incident) to Change Request Summary (on Change Request)
  • Customer Name (from Incident) to Requester (on Change Request)
  • Description of Impact (from Incident) to Description (on Change Request)
  • CI Name (if the incident is linked to a Configuration Item) to Related CI (on Change Request)
  • Urgency & Impact (from Incident) to Risk Assessment fields (on Change Request)
• Matching Criteria: The Push Fields action can be configured to search for an existing Change Request if one is already in progress for this incident, or to create a new one if none exists. A common criterion might be linking the Change Request back to the Incident ID.

Benefit: This dramatically reduces the time and effort required to document a change request. It ensures that all critical information from the incident is captured in the change request, improving accuracy and completeness for subsequent approvals and execution.

Example 2: Asset Update from Incident

Scenario: A user reports a hardware issue with their laptop. The IT support team diagnoses it as a faulty device and needs to initiate a replacement process, which involves updating the asset record.

How Push Fields Helps:

• Once the support agent marks the incident as “Resolved” and selects “Hardware Replacement” as the resolution type, a Filter can be triggered.
• Source Form: Incident Management
• Destination Form: Asset Management
• Fields to Push:
  • Asset ID (if linked on the incident) to Asset ID (on Asset Management)
  • Status (e.g., “Decommissioned” or “Under Repair” on Incident) to Current Status (on Asset Management)
  • Notes from Resolution (on Incident) to Service History Notes (on Asset Management)
• Matching Criteria: The primary matching criterion would be the Asset ID.

Benefit: This ensures that the asset record is kept up-to-date automatically, reflecting the current state of the hardware. This is crucial for inventory management, warranty tracking, and financial reporting.

Example 3: Knowledge Article Linking

Scenario: During the resolution of an incident, the support agent finds a knowledge article that successfully resolved the issue. They want to link this article to the incident for future reference.

How Push Fields Helps:

• When an agent selects a Knowledge Article ID on the Incident form (perhaps from a search result or a dropdown), an Active Link can be triggered.
• Source Form: Incident Management
• Destination Form: Incident Management (linking to itself or a related association form)
• Fields to Push:
  • Knowledge Article ID (from the selected article on Incident) to Related Knowledge Article ID (on Incident or an association form)
  • Knowledge Article Title to Related Knowledge Article Title
• Matching Criteria: The current Incident ID.

Benefit: This creates a direct link between the incident and the solution, allowing for quick lookup and analysis of recurring issues and their resolutions. It also helps in identifying popular or effective knowledge articles.

Configuring Push Fields Mapping

The configuration of a Push Fields action is typically done within the workflow definitions of Active Links, Filters, or Escalations. The exact interface might vary slightly depending on the specific version or product (e.g., BMC Helix ITSM vs. older Remedy versions), but the core concepts remain the same.

When you are setting up a Push Fields action, you’ll generally encounter the following key components:

1. Selecting the Action Type

Within the workflow editor (e.g., Active Link Manager, Filter Manager), you’ll add a new action and choose “Push Fields”.

2. Defining the Source and Destination

This is where you specify where the data is coming from and where it’s going:

• Source Form: This is usually the form where the workflow is currently executing (e.g., the form the user is interacting with).
• Destination Form: This is the form where the data will be pushed.

3. Establishing the Mapping

This is the heart of Push Fields mapping. You create a list of field-to-field transfers:

• Source Field: The field on the source form whose value you want to transfer.
• Destination Field: The field on the destination form that will receive the value.
• Data Type Compatibility: It’s crucial that the data types are compatible or can be implicitly converted. For example, pushing a date to a date field is straightforward. Pushing text to a number field might require specific handling.

4. Specifying the Operation Type

Push Fields can perform two main operations on the destination form:

• Update: If records matching your search criteria already exist on the destination form, their fields will be updated.
• Create: If no records match your search criteria, a new record will be created on the destination form.
• You can often configure options for what happens if a record is found (e.g., update only specific fields, or don’t update if the destination field is already populated).

5. Defining Search or Qualification Criteria

This is critical for both Update and Create operations. You need to tell the system how to find existing records or determine if a new one needs to be created.

• For Update: You specify the fields and values that must match to identify the record(s) to be updated. This often involves pushing values from the source form to identify the target record (e.g., pushing Incident ID to find the related Change Request).
• For Create: You might specify a qualification that, if it *doesn’t* find any records, then a new one should be created. Alternatively, the system may just try to create if no match is found by the update criteria.
• Unique Identifier: It’s best practice to use unique identifiers to ensure you’re updating the correct record.

6. Advanced Options

Depending on the platform, you might have advanced options like:

• Overlay Type: Specifying whether the push should be a “merge” (updating existing values) or “replace” (overwriting existing values).
• Pre- and Post-Processing: Running other actions before or after the Push Fields operation.

Official Documentation Reference: For detailed step-by-step guides and specific syntax for BMC Helix ITSM, you would typically refer to the official BMC documentation. Searching for “Push Fields action BMC Helix ITSM” on BMC’s documentation portal or on docs.bmc.com is your best bet.

Key Considerations and Best Practices

While Push Fields is incredibly powerful, using it effectively requires careful planning and adherence to best practices.

1. Understand Your Data Flow

Before you start configuring, map out your data. What information needs to go from where to where? What triggers this transfer? What are the conditions?

2. Use Meaningful Field Names

In your source and destination forms, ensure fields are named clearly and descriptively. This makes mapping and troubleshooting much easier.

3. Leverage Unique Identifiers

When updating records, use fields that uniquely identify a record (like IDs, email addresses, or specific reference numbers) in your qualification criteria. This prevents accidental updates to the wrong records.

4. Handle Data Type Conversions Carefully

While the system often handles basic conversions, be mindful of pushing data between fields of vastly different types (e.g., complex text with special characters into a numeric field). You might need to use Active Link guides or escalation filters with functions to format the data before pushing.

5. “One Form to One Form” Rule

Remember the limitation: one Push Fields action targets one destination form. For multiple destinations, use multiple actions, but be aware of the performance implications.

6. Test, Test, Test!

Never deploy Push Fields mappings to production without thorough testing in a development or QA environment. Test with various scenarios: existing records, new records, edge cases, and data variations.

7. Document Your Workflows

Keep detailed documentation of your Push Fields configurations, including the source and destination forms, the fields being mapped, the qualification criteria, and the intended business logic.

Troubleshooting Common Push Fields Issues

Even with careful planning, you might encounter issues. Here are some common problems and how to address them:

Interview Relevance

Understanding Push Fields mapping is crucial for anyone aspiring to a role involving ITSM administration, workflow development, or application configuration in systems like BMC Helix ITSM. Here’s why it’s a common interview topic:

Conclusion

Push Fields mapping is not just a technical feature; it’s an enabler of efficiency and accuracy within complex enterprise systems. By automating the transfer of data between records and forms, it empowers IT professionals to streamline workflows, reduce the burden of manual data entry, and ensure the integrity of their information assets.

Whether you are involved in ITSM, asset management, or any domain where data needs to flow intelligently, mastering Push Fields mapping is an essential skill. It allows you to build robust, automated solutions that contribute significantly to operational excellence.

For those working with BMC Helix ITSM or its predecessors, understanding and leveraging Push Fields is a cornerstone of effective workflow customization and process automation. Continue to explore the official BMC documentation for the most up-to-date information and advanced techniques.

Related Resources:

• BMC Support Resources
• Automation in AR System (Older Remedy versions) – Search for Push Fields within relevant sections.
• Workflow and Automation in BMC Helix ITSM – Navigate to actions like Active Links, Filters, and Escalations for specific Push Fields configurations.