#Humanitarian0 discussing

It also depends a bit on whether you are giving away only diapers, or also other products (or planning to do that in the future). In that case, if it does not interfere with other business processes, you can also 'unlock' the products/pricelists and orders within the standard sales process. And perhaps a flow or even a quick action could reduce the administrative overhead and speed up things.

But it could also be as simple as adding a custom object to either accounts or contacts (depending on what a family is in your org) with a parent-child relationship to an object called something like diaper donation. Could just have three fields: date of handout, number of diapers and handler (or something like that). If you use create a quick action on the parent you can prefill date (using now() as a prefilled value) and handler (current user), which makes it really quick for the person who has to enter the donations. Even on a mobile phone for example.

After that you could add bells and whistles: e.g. e-mail confirmation of the donation, simple inventory management etc.

In general when the requirement is a bit more complex, it is good practice to define your requirement in smaller user stories. They have a general form like: "As a <role> I can <capability>, so that <receive benefit>". That way you can keep oversight and reduce the chance that you make a design choice, which will work against you later (like going for only a custom object when you actually have other requirements too).