However in this use case it sounds like your end user are non techies and more about growing grapes so I would argue they should not need TTN access at all and instead should just have some friendly web portal where they can see their data and be abstracted from the tech. Just my thoughts.
Hello, yes that’s correct 
That question come into my mind, because I am using a Jeedom box with MQTT to generate an alarm when a temprature is below a limit.
All of the measures are sent to a MySQL via TTN and I provide a web application to see the graph of the temperatures.
But to generate the alarm, I chose jeedom. With MQTT, I can read the message sent to TTN. That’s work a bit in parallel. But the advantage, I can send a Telegram message and the wine owner can validate the alarm. Additionally, when a alarm “ring”, the domotic will allow me to ring a siren, or turn on a gyrophare ot the light of the wine domain.
That question, about one or two application by wineyard, come into my mind, because (from Jeedom) I can not detect from which wineyard the message are collected and receive via MQTT. I could update the station, adding a new parameter to identify the field, but I want to keep the messages as short as possible.
As in TTN payload, I can read ‘dev_id’, I could create to application, one for each field
{“dev_id”:“wineyard-1”}
{“dev_id”:“wineyrad-2”}
I beleive that a good idea, specialy if the one owner leave the project.
I am checking my existing application in v2 cluster, and I observed, the Process ID of the HTTP integration , has the name as my application. I beleive the dev_id value is the name of your application and NOT the name of the Process ID of the HTTP integration?
PS: For now the user will not have access to TTN console. They will not understand, as I do not understand wine, excepted in a glass
Cheers and have a nice day.