ZMP controller reported an airspace violation because the controller did not ensure the handoff was ...

Narrative:

I was working the radar position at sector xx at ZMP ARTCC. I had bad rides and a few aircraft requesting different altitudes. I was working somewhere between 18-22 aircraft by myself which is not uncommon. The sector was still green. Denver center was in the process of solving a situation between two aircraft that were coming together in level flight at FL350. Both data blocks were flashing and the loss of separation would occur in denver center's airspace. (There was no loss of separation as far as I could tell.) both aircraft were coming to me from denver sector xy. Both aircraft were also flashing to me in a handoff status. Denver proceeded to turn one aircraft to the north and solved the conflict.in the process they stopped the handoff flash to me on the lead aircraft whose call sign is aircraft X. So aircraft X was not on my scope anymore as they had taken the data block back. Here's where the issue occurred: three minutes later they started the flash on aircraft X to me and he was one minute away from my airspace. He was showing level at an interim altitude of FL350 with a requested altitude of FL370 I believe. I quickly took the handoff after doing a traffic search and started the flash to kansas city center by typing 'K cid enter' since he was a corner cutter and would only be in my airspace for two minutes. Since kansas city sector xx was open the data block began flashing to them instead of kansas city sector xy. Kansas city sector xx took the handoff a few seconds later and I did not notice that they had the hand off until the aircraft was one hit inside kansas city center's airspace upon which time I called kansas city sector xy to do a late point out on aircraft X. I wrongly assumed that the data block would flash at the correct sector based on the interim altitude. I was busy and I forgot that I needed to flash the aircraft specifically to kansas city sector xy in such a situation.I recommend that en route automation modernization (eram) be updated to allow us to flash aircraft to any adjacent center based on the interim altitude. I understand this probably will not happen but it would have been helpful in this situation.

Original NASA ASRS Text

Title: ZMP Controller reported an airspace violation because the controller did not ensure the handoff was routed to the correct sector. The reporter thought the En Route Automation Modernization computer would send it to the correct sector based on the interim altitude.

Narrative: I was working the radar position at sector XX at ZMP ARTCC. I had bad rides and a few aircraft requesting different altitudes. I was working somewhere between 18-22 aircraft by myself which is not uncommon. The sector was still green. Denver Center was in the process of solving a situation between two aircraft that were coming together in level flight at FL350. Both data blocks were flashing and the loss of separation would occur in Denver Center's airspace. (There was no loss of separation as far as I could tell.) Both aircraft were coming to me from Denver sector XY. Both aircraft were also flashing to me in a handoff status. Denver proceeded to turn one aircraft to the north and solved the conflict.In the process they stopped the handoff flash to me on the lead aircraft whose call sign is Aircraft X. So Aircraft X was not on my scope anymore as they had taken the data block back. Here's where the issue occurred: Three minutes later they started the flash on Aircraft X to me and he was one minute away from my airspace. He was showing level at an interim altitude of FL350 with a requested altitude of FL370 I believe. I quickly took the handoff after doing a traffic search and started the flash to Kansas City Center by typing 'K CID enter' since he was a corner cutter and would only be in my airspace for two minutes. Since Kansas City sector XX was open the data block began flashing to them instead of Kansas City sector XY. Kansas City sector XX took the handoff a few seconds later and I did not notice that they had the hand off until the aircraft was one hit inside Kansas City Center's airspace upon which time I called Kansas City sector XY to do a late point out on Aircraft X. I wrongly assumed that the data block would flash at the correct sector based on the interim altitude. I was busy and I forgot that I needed to flash the aircraft specifically to Kansas City sector XY in such a situation.I recommend that En Route Automation Modernization (ERAM) be updated to allow us to flash aircraft to any adjacent center based on the interim altitude. I understand this probably will not happen but it would have been helpful in this situation.

Data retrieved from NASA's ASRS site and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.

Attributes
ACN	1434518
Time
Date	201703
Local Time Of Day	1201-1800
Place
Locale Reference	ZMP.ARTCC
State Reference	MN
Environment
Light	Daylight
Aircraft 1
Make Model Name	EMB ERJ 145 ER/LR
Operating Under FAR Part	Part 121
Flight Phase	Cruise
Flight Plan	IFR
Person 1
Function	Enroute
Qualification	Air Traffic Control Fully Certified
Experience	Air Traffic Control Time Certified In Pos 1 (yrs) 1
Events
Anomaly	ATC Issue All Types Airspace Violation All Types Deviation - Procedural Clearance Deviation - Procedural Published Material / Policy Deviation - Track / Heading All Types

ZMP controller reported an airspace violation because the controller did not ensure the handoff was routed to the correct sector. The reporter thought the en route automation modernization computer would send it to the correct sector based on the interim altitude.