Skip to Main Content

This is an IBM Automation portal for Integration products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Workspace App Connect
Created by Guest
Created on Aug 30, 2023

Use of user defined paramters (UDP) in event filters on monitoring events

Currently, there is no way we can check against static values for event filters (whether to emit an event or not). It would have been good to add the support of UDP on event filters so that events can be defined with expressions like IF (ENV == DEV || ENV == QA) then emit this event else not (ENV is the defined UDP on the flow).

Idea priority Urgent
  • Admin
    Ben Thompson
    Jan 15, 2024

    Idea review. Thank you for taking the time to raise this suggestion. As noted, when specifying an event filter, you can use xpath expressions to examine a value held in part of the logical message tree in order to decide whether or not to emit the event. Details here:

    This capability is incredibly flexible because the choice of whether to emit an event can be made on a message-by-message basis as opposed to a fixed setting for an entire environment. In the proposed idea, the decision to emit an event is instead based upon the value of a message flow's user-defined property. Similarly, one could imagine using references to other static values such as the name of the flow, its containing application or the name of the integration server to which it is deployed. These kind of environmental static values are available in ESQL and graphical data maps. In concept we understand the requirement along these lines and we agree it would bring additional benefit. In the meantime of course, it would be possible to apply a workaround of sorts and take these kind of static environmental values and place them into the logical tree using a prior message flow node and so be able to reference them in later nodes when deciding whether to emit a monitoring event. This would only work in message flow nodes downstream so wouldnt be able to be applied directly to an input node. So, whilst somewhat of a fringe requirement we're happy to move it to Future Consideration status and test the appetite from the user community - this is the first time this has been raised many years after monitoring events have been available, but its never too late to make things *even* better of course ;o)