# Project Structure Management: Best practises

**URL:** <https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802>\
**Category:** Ignition\
**Tags:** ignition81, perspective\
**Created:** [January 26, 2024, 8:59am UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802 "2024-01-26T08:59:16Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [January 26, 2024, 1:57pm UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/2 "2024-01-26T13:57:23Z")

</div>

An architecture to consider:

> [@Where do/should Gateway Scripts live with respect to an inherited project structure?](https://forum.inductiveautomation.com/t/where-do-should-gateway-scripts-live-with-respect-to-an-inherited-project-structure/83460/3):
>
> Put all of the logic in project library scripts, in the "universe" project at the root of your hierarchy, if you must. Then, in leaf projects, use one-line calls to the appropriate logic from event scripts and message handlers. (I don't agree with your desire, but this is what you must do to achieve it.) I recommend you not put all your scripts (eggs) in one inheritable project (basket). I recommend a hierarchy something like this: universe ├bg\_common │├gsp │├background1 │├background2 │└we…

Possibly expanded as described here:

> [@Switching between Ignition Perspective projects](https://forum.inductiveautomation.com/t/switching-between-ignition-perspective-projects/83795/3):
>
> This strikes me as a really bad idea. Consider a chain of inheritable projects instead, if you must. Just make sure the projects closest to the root need no resources from projects further from the root. Consider the project hierarchy from this comment: For your case, replace perspective\_common with two or three resource projects in a chain, where the UI leaf projects inherit from the last one. Something like this, perhaps: └ui\_common ├perspective\_scripts │└perspective\_embeds │ └pers…

The key is to push _ **well-tested** _ resources towards the root of the hierarchy so they can be shared.

It can also be helpful to duplicate projects for development work, and then send the updated resources (via _export...send to project_) in a batch back to the original project. Similar to making git branches, but can be done with or without git. (Delete the duplicate project immediately after its resources are merged where intended.)

---

_[View the full topic](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802)._
