A problem far too common
This is a very common issue. You are describing a rather 'advance' configuration, where the grid and the form are co-located. But you can run into this problem with pretty much any data-driven application.
It goes without saying that if one sees a list of items, the 'add' action should be in close proximity to that list.
There are 3 things that will mess things up with such 'add' feature:
- Filters
- Sorting
- Pagination
Some IA fundamentals
Data-driven systems have the famous triplet of page types (there are many names to each type, I'm just using arbitrary ones). It would help thinking of an e-commerce shop:
- Unique page - a one-off page, no need for database. For example, terms and conditions.
- Records page - a page that renders a list of (database) records, for example hard drives. AKA a catalogue page, a list page, or items page.
- Record page - a page that renders a single (database) record, for example, a specific hard drive. AKA a product page, or an item page.
Cause #1 - needs follow design
The first cause for this issue is that user needs were not accounted for while designing the interface.
Here are, what I believe the four user needs the design has to account for:
Finding something
The grid (a records page/control), provides a multitude of items so users can find a particular item. This satisfies the need 'As a user I'd like to find a particular item'. Filters and sorting both help with this task; pagination is just a way to reduce cognitive load via clustering.
Editing something
The task model of editing an item has two steps:
This is perfectly in tune with filters/sorting/pagination. No problems here.
Adding something
The form (a record page/control), through the add control, serves a different need - 'As a user I'd like to add an item'.
The important bit here as that, in essence, if the user knows they have added an item, it's job done. The grid, serving to find an item is not needed here. So, in theory (it really depends what the app does) once the user has added something, they may not wish to see it on the grid - they've just added it, why would they like to search for it.
Adding something then do something with that something
But there are exceptions - if you add a contact to your phone contact, you may wish to call that contact after adding it. So the records display does have to update so the new contact is in view.
Cause #2 - too much space
A lot of usability problems can be solved if one takes the 'mobile first' approach. Thinking small, often lead to more usable solutions than having to 'fill the display space'.
The solution
This is what happens on my iPhone contacts app, which is the usable solution in my view:
- A grid displays the list of contacts. There's a visible search field and an add button.
- If you touch the search field (filter field) the add button disappears - you either search for something or you add something. But you can't have a scenario where you can't see your added item because a filter is in place.
- When you add a record, the grid scrolls so the new item is in sight. (although the iPhone doesn't do it, I think some highlight-animation on the new item would be appropriate, like a green background colour that fades to the background colour of all other items - this site does it, but I can't remember where).
So, a filter while adding - out of the question. Both sorting and pagination still allow the grid to have the new item in view.
Here is the iPhone before you click search:

And after hitting search:
