Forum Stats

  • 3,728,131 Users
  • 2,245,555 Discussions


How to filter the entity collect incidents


I have a model that will allow users to load data from a custom object that is a child of an existing incident. I want to give the user the ability to add new records to the custom object so I'm using the entity collect control.

This custom object will contain a long history of records for the customer. I only want to show the customer a subset of the records. But unlike the entity container control, there is no filter capability on the entity collect control. I do this frequently, so having the ability to filter existing instances from within an entity collect control is pretty important. How do I do this?

For example, for a grant applicant, they may have applied for several projects to be funded, but we did not award some of them. When they load the grant application into the closeout report model from OSvC, I want to filter out the projects that were not awarded and only let them submit dollars spent for the awarded projects.

I can lock them out of the not awarded instances easily enough, but they will still see them, they will not be in any sorted order, and they will clutter up the screen with unneeded information. They may have dozens of entries from budget change requests over the life of the grant and I only want to show them the current budget items to add the monies spent. I can't use an ad hoc query for this because that entity wouldn't be allowed to map out to OSvC. I can't use a regular entity container because the user can't add new records.

Is there an approach that will allow me to show them only the approved budget line items for the grant, add new line items, and save it all back to the existing incident records?

Thank you,



  • Richard Napier
    Richard Napier Member Posts: 180 Silver Badge

    Hello Scott

    could I ask for a clarification? The custom object that is a child of incident, I assume it is loaded at start (since a dynamic load would be read-only if my memory serves) ? And that object needs to be mapped back out at the end?

    is it actually possible to use an entity collect in that case? Surely since the object has existing rows we cannot use a collect in that case, only a container? I may be wrong I’m just thinking aloud late at night. If that is the case then use a container for the existing records and filter it, and use a second entity to create new instances with a similar data structure, then merge them into a single outbound mapped entity.

    lets talk!

  • Matt Sevin-Oracle
    Matt Sevin-Oracle Member, Moderator Posts: 308 Employee

    Hi Scott,

    Sounds like you might need more relationships than the one you seem to be relying on. For example, there must be a semantic difference between existing child objects, those you wish to show or not and those that would be collected as new (otherwise there would be no issue). From you example scenario it sounds "existing" budget change requests (as in all of them that currently exist), is different from "new" budget change requests which is also a different relationship (or perhaps should be) from "denied" budget change requests. Perhaps with a model that represents those differences you could map to the appropriate children objects through the required relationships for "display" vs "collect new".

  • Scott Heidenreich
    Scott Heidenreich Member Posts: 119 Red Ribbon

    Hi Richard,

    Thank you for your reply. We can use an entity collect on a mapped in object to allow the user to add new records to the custom object. This is an important function for being able to update an existing incident. However, because the custom object is mapped in with the incident, we cannot infer new instances. Only the user can create a new instance in the object. As a result, I can't merge entity records into a mapped custom object that is loaded at start from the incident because I can't infer a new instance in the mapped custom object in order to copy over the values.



  • Scott Heidenreich
    Scott Heidenreich Member Posts: 119 Red Ribbon

    Thank you for your reply, Matt.

    There are semantic differences between instances of the entity and I thought of using a different relationship to identify the instances I want to let the user see, then using an entity collect for that relationship. I received an error when I attempted it, but now that I think about this again, I may have been setting the relationship up incorrectly. I will try setting up a new relationship and assigning only the instances I want the user to see to that relationship, and see if I can put an entity collect control on the screen for that new relationship.

    I'll post back here what I find when I try it.

    Thank you,


  • Richard Napier
    Richard Napier Member Posts: 180 Silver Badge

    Hi Scott

    Thanks for the clarification. I should pay more attention to the context of questions or not answer late at night! I get the scenario now re Incident / the custom object.


Sign In or Register to comment.