The Challenge

Because Views are essentially filtered windows into the large world of all possible tickets, individual tickets don't actually live anywhere. We were struggling with the occasional ticket getting lost in the mix while moving through our support flow, and because we don't use direct assignment on our team, we couldn't do something as simple as a view of Unassigned tickets that are > New.

Additionally, we wanted to be able to use Explore to see what was entering each view over time without having to look at each ticket's Events. If we could see what tickets were missing from all views, even better.

The Solution

We created two custom fields—checkboxes—for each main view; one for when the ticket was actively in a view, and one that never got unchecked and was used as a way to track if a ticket had ever entered a view. Triggers check and uncheck these view fields, and your view conditions can be nearly as simple as "[View Box] is Checked".

Side Note: An accidental benefit of this method is that it allows your views to be more complex than view conditions would allow; sub-conditions that wouldn't have worked can now be separated. For example, a set of triggers could add tickets to "View A" if:

Trigger 1: Tickets are New
Trigger 2: Assignee is Charlie and ticket has the tag "books"
Trigger 3: Ticket is Open and has no Assignee

In a View condition, you wouldn't be able to have all three types of tickets because there are conditions to the conditions. You could have "NULL" and "Charlie" as assignee options in the ANY condition, but if you added the books tag there, you'd get tickets that are assigned to Mei and tagged with books. If you added books to the ALL condition, you'd miss the non-books related New and Open tickets.

The Instructions

Create the Custom Fields

Create a checkbox field to populate the view — click Admin > Ticket Fields (under Manage) > Add Field > Checkbox. We used the naming convention "View: [Name]", and added the tag v_[name]. For Example, "View: Billing", and v_billing
Create a second checkbox field to track whether or not the ticket was ever in the view — we used the template "View Tracking: [Name]", and added the tag v_track_[name]

Create the Check trigger(s)

Create a trigger (or multiple) that will be used to populate the view. Click Admin > Triggers (under Business Rules)> Add Trigger. We use the naming convention "View: [Name] - Reason", so an example would be View: Billing - Escalations
This should contain all the conditions for one-or-more reasons a ticket would move into the view.
Add "[Your View Field] - Checked" as the action

Create the Uncheck trigger

Create a trigger that will be used to remove a ticket from the view. We use the naming convention "View Remove: [Name]".
This should include things you may normally include in the view conditions, but in reverse, like "Status - is - Pending". Think about what else would remove the trigger from a view — if some other View field is checked? If the ticket is escalated somehow?
Add "[Your View Field] - Unchecked" as the Action
Assuming you intend to report on these fields, this is where things can get complicated: add anything you've added to your Uncheck trigger to your Check trigger, in reverse. If I added "Pet Type - is - Cat" as a condition to remove a ticket from the Dogs view, I should go up to the Check trigger for the Dog view and add "Pet Type - is not - Cat". This ensures that the boxes aren't checked then unchecked instantly, which would corrupt your reporting.

Create the Tracking trigger

Create a trigger to track whether or not a ticket was in a certain view We use the naming convention "View Track: [Name]"
This one's easy: it should simply check if "[Your View Field] - checked" and "[Your View Tracking Field] - Unchecked", then check the tracking field. Nothing will uncheck this, since it's the tickets permanent record of being in the view once.

Create the View

Click Admin > Views (under Manage) > Add View.
Keep this as simple as possible! Add "[Your View Field] - checked" and at least one of the required ALL conditions (Assignee, Group, Requester, Status, or Type). Choose something that won't interfere with the triggers — we use "Status - is not - Closed"

Notes:

We create queries to look at a few things like tickets where a certain view field is checked (it lags a bit, but still gives a general idea during the day), tickets with the ticket tracking field over time, and most importantly, tickets where no View fields are currently checked. Once you filter out the reasons tickets wouldn't be in a view (because they're Pending, perhaps), you'd be left with missing tickets — if they do have a home, that means you need to make a Checkbox system for that view!
Not every view has a Checkbox system — we have lots of miscellaneous queues that are basically filtered down version of the larger queues, or personal iterations for a manager. However, every ticket should be showing in at least one of the Checkbox views, and just might also show in another view.