# Custom Event States?

**URL:** <https://forums.losant.com/t/custom-event-states/5872>\
**Category:** Feature Request\
**Tags:** events\
**Created:** [June 24, 2025, 11:28am UTC](https://forums.losant.com/t/custom-event-states/5872 "2025-06-24T11:28:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jason\_Walton](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.losant.com/jason_walton/32/5023_2.png) [@Jason\_Walton](https://forums.losant.com/u/Jason_Walton)\
**Post date:** [June 24, 2025, 11:28am UTC](https://forums.losant.com/t/custom-event-states/5872/1 "2025-06-24T11:28:51Z")

</div>

Our use case leans heavily on event creation and report. Often times, we find that a condition may take weeks to clear due to need for use intervention. It would be nice to have custom event states for more complex implementations where ‘New’, ‘Acknowledged’, and ‘Resolved’ might not fully define the state of the Event.

---

<div class="post-metadata">

**Author:** ![Dylan\_Schuster](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.losant.com/dylan_schuster/32/2850_2.png) [@Dylan\_Schuster](https://forums.losant.com/u/Dylan_Schuster)\
**Post date:** [June 24, 2025, 12:02pm UTC](https://forums.losant.com/t/custom-event-states/5872/2 "2025-06-24T12:02:22Z")

</div>

We’ve had such a request before and we have it logged in our issue tracker. I’ll add your +1 to the request.

Have you considered [event tags](https://docs.losant.com/applications/events/#tags) as a solution? You could adopt a specific tag key (i.e. “customStatus”) and give it any value. You can then query events by that tag.

---

<div class="post-metadata">

**Author:** ![Jason\_Walton](https://sea1.discourse-cdn.com/flex015/user_avatar/forums.losant.com/jason_walton/32/5023_2.png) [@Jason\_Walton](https://forums.losant.com/u/Jason_Walton)\
**Post date:** [June 25, 2025, 1:48pm UTC](https://forums.losant.com/t/custom-event-states/5872/3 "2025-06-25T13:48:04Z")

</div>

Thanks Dylan. We are using event tags for a variety of other reasons, and i suppose we could implement custom\_state over there and manage it outside of the native state. Thats a good suggestion, thank you.