Your diagram makes this easier to answer, because it shows two different things that people usually try to squeeze into one workflow.
The incident reports are event driven. A moderator sees botting in Bloody Ice, fills the form, one row gets created.
The Alz and FG rates are a daily time series. They exist whether or not anyone reports an issue. If those fields live in the same form, five reports on Tuesday give you five copies of Tuesday’s economy numbers and your monthly analysis starts double counting. Capture them separately into two tables, then join on date when you build the report.
The pieces themselves:
Capture. The Form Trigger node covers everything in your mockup natively, no external tooling needed. Date, issue category as a dropdown, details, resolution taken. Give every report an ID the moment it is created.
Storage. Sheets works to start, but look at your own step 5. Resolved On and Resolved By mean a report gets updated after it exists, not just appended. Updating a specific row in Sheets means searching for it first and hoping two moderators are not editing at the same second. Postgres or Supabase removes that problem and costs nothing at this size.
Reporting. A second workflow on a Schedule Trigger. Daily, weekly and monthly can be three schedules calling the same sub workflow with a different date range. Pull the period’s rows, group by category, count, join the economy rows by date, and you have the trends panel from your step 4.
One thing about the AI box in the middle. Do the counting in code or SQL first, then give the model the summary numbers and let it write the narrative. If you hand it raw rows it will invent patterns, and in an economy report a made up trend is worse than no report.
Bloody Ice and Alz suggest Cabal. Is that right, and roughly how many reports a day are you expecting? Volume decides whether Sheets is fine or you should start on a database.