# How to make a BPM fire when a field is changed in a BAQ Report form

**URL:** <https://www.epiusers.help/t/how-to-make-a-bpm-fire-when-a-field-is-changed-in-a-baq-report-form/120543>\
**Category:** Kinetic ERP\
**Tags:** kinetic\
**Created:** [November 3, 2024, 11:57am UTC](https://www.epiusers.help/t/how-to-make-a-bpm-fire-when-a-field-is-changed-in-a-baq-report-form/120543 "2024-11-03T11:57:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![R.Zimmer](https://www.epiusers.help/letter_avatar_proxy/v4/letter/r/6bbea6/32.png) [@R.Zimmer](https://www.epiusers.help/u/R.Zimmer)\
**Post date:** [November 3, 2024, 11:57am UTC](https://www.epiusers.help/t/how-to-make-a-bpm-fire-when-a-field-is-changed-in-a-baq-report-form/120543/1 "2024-11-03T11:57:15Z")

</div>

I have a BAQ report that I run from a menu in Kinetic. The BAQ report form has an Option01 field which is a date field.

I would like a BPM to fire when this field is changed before previewing or printing the BAQ report so that I can populate the UD02.Key1 with the userid and UD02.Date01 with the Option01 date field via code in the BPM.

Is this possible?

I tried finding a callcontextbpmdata service in the method maintenance with no luck.

Please Help!!!

Thanks,  
Richard

---

<div class="post-metadata">

**Author:** ![klincecum](https://www.epiusers.help/user_avatar/www.epiusers.help/klincecum/32/100137_2.png) [@klincecum](https://www.epiusers.help/u/klincecum)\
**Post date:** [November 3, 2024, 2:53pm UTC](https://www.epiusers.help/t/how-to-make-a-bpm-fire-when-a-field-is-changed-in-a-baq-report-form/120543/2 "2024-11-03T14:53:21Z")

</div>

> [@R.Zimmer](#):
>
> Is this possible?

Technically, yes, but let’s get a little explanation of what’s going on first.

> [@R.Zimmer](#):
>
> I tried finding a callcontextbpmdata service in the method maintenance with no luck.

Yeah, there is no such thing. CallContextBPMData is a special dataview that is available with each BPM call, it is not a service. It is intended to be populated and used before a bpm call and is available inside the next bpm, and immediately after return. No guarantees after that.

The problem with the call context data for this particular application is that a report from a menu is most likely to be called from a `SubmitToAgent` (or a `TransformAndSubmit`) call, which schedules the report to be run by an outside agent, asynchronously, where the call context data will not be available. You can get away with using it with a `RunDirect` call, but that’s another story.

You might want to look into an alternative way to get what you want done, so please explain more, but in the meantime, I will explain what you can do.

Depending on the method called, (`SubmitToAgent` or `TransformAndSubmit`), you can add a pre-processing BPM on the appropriate one, and do something like this. (Off the cuff)

### Pre-Processing on the appropriate one of these → Ice.Rpt.BAQReport.SubmitToAgent, Ice.Rpt.BAQReport.TransformAndSubmit

```cs
var report = ds.BAQReportParam.FirstOrDefault();

if(report.BAQRptID == "YourReport")
{
    
    var userID = Session.UserID;
    
    DateTime yourDate;

    bool success = DateTime.TryParse(report.Option01, out yourDate);
    
    if(success)
    {
        //Go write your stuff
    }
}

```

* * *

Now with all that being said, please explain more on what you are doing in case there is a better way to do it. It might be real important for matching because you will not have a task ID at this point.

---

<div class="post-metadata">

**Author:** ![Hally](https://www.epiusers.help/user_avatar/www.epiusers.help/hally/32/1263_2.png) [@Hally](https://www.epiusers.help/u/Hally)\
**Post date:** [November 3, 2024, 5:04pm UTC](https://www.epiusers.help/t/how-to-make-a-bpm-fire-when-a-field-is-changed-in-a-baq-report-form/120543/3 "2024-11-03T17:04:32Z")

</div>

That information should be available in the tables related to the report task, not really following why you would want to store this information again… I am with @klincecum with regards to asking for further explination…