Custom App development - is this the right approach for my use case?

[LonLandry1]

Howdy Community,
I need to do some tricky reporting on global tables (many tables) with the help of well defined script includes.
Then populate data into custom tables that are used for reporting & dashboards.
I found populating reports & dashboard has a very long lag-time, so this seems to be a simple solution as opposed to calling the script includes thru report or dashboard directly.

The report / dashboard does not actually need to be live - I update table with scheduled job every day.
I use a script includes & a server side script (all in global scope) to do the work I need.

Currently, I populate the results in a custom table in the global scope (u_table_name) with fields that also start with u_. Records are routinely added & removed from this table. 

Should the custom table I am populating & using for reporting be in a custom app or is it okay to leave in global scope?

Thanks for your help & time!

[Rajesh Chopade1]

hi @LonLandry1 

- If your custom table is part of a larger, scoped reporting or data aggregation solution that is self-contained (with its own business logic, scheduled jobs, and scripts), then it makes sense to place it in a custom application. This will allow you to manage all related assets (scripts, scheduled jobs, and table) within one modular application, which simplifies maintainability and security.

- If the table is just a simple container for storing report data and you want it to be accessible globally without worrying about scope or access controls, then it is fine to leave it in the global scope. However, you should still consider future-proofing your solution by moving to a scoped application as your reporting requirements grow.

In most cases, as your reporting and dashboard solution evolves and becomes more complex, it is a good idea to start using a custom scoped application to ensure you have better control over the table, scripts, and related functionality.

I hope my answer helps you to resolve your issue, if yes please mark my answer helpful and correct.

thank you

Rajesh

[Uncle Rob]

For me its a function of risk tolerance, intended interaction with other scopes, and source control.

The more negative you feel about unplanned modifications to this app's functionality, the more you need to consider scope.

The more negative you feel about other scoped apps interacting with it (creating records, calling functions, reading, etc), the more you need to consider scope.

The more you want to use things like git or other source controls, vs update sets, the more you should consider scope.

[LonLandry1]

I am not sure to mark which is correct; both are great pieces of advice...