Save Project As - Create a folder for this local project

bdewitt_olsson

The option to "create a folder for this local project" should be available when "saving a project (aprx) as." This option is available (and seemingly recommended) when creating a new project, so it should also be available when saving a copy of a project to a new location. Since ArcGIS Pro projects create an unwieldy mess of ancillary files and folders, the only way I've found to effectively manage them is to quarantine them to their own folder using this option. The lack of this option in the Save As process appears to be an egregious inconsistency that encourages users to practice poor content management.

RTPL_AU · ‎10-26-2025

This should be implemented as optional 'Specify Default Folder or Create New Default Folder or use the Current Defaults' menu.

We will save multiple revisions of a project to a folder as a job progresses. Rev A, Rev B, Rev 1, etc.
They all may or may not use the same default folders or databases. In our case, the aprx is not saved in the default folder as we have the maps/jobs/work product separated from data.
Having Pro NOT create a new folder to save each new copy of the aprx has made life a lot better.

In my workflows I would like to specify a 'File 13' folder for all the extra fluff so that my default folder and aprx saved locations can be cleaner; without having the ImportLogs or GPMessages folders cluttering up the place.

ChrisUnderwood · ‎10-28-2025

Hello @bdewitt_olsson , do these steps work for you ?

From Save Project As > select a folder > from New Item select Folder > a new sub-folder is created > select that folder > enter a Name & Save.

bdewitt_olsson · ‎10-28-2025

Yes, of course those steps work. My point is the Save As process should look and feel the same as the process of creating a new project to provide consistency to the end user. Currently, when using the Save As option, it's unclear whether or not a new folder will be created automatically to house the aprx. This occurred to me as a need because I'm part of a team that oversees a few hundred Pro users, and inconsistencies like this make it very difficult to encourage proper content management.

An addendum: as @RTPL_AU and I both hinted at above, the real problem here is the mess of folders and files an aprx infects its host folder with. If this information was stored in the aprx file itself or in a different directory or at the very least made hidden in Windows and Pro by default, there would be no need to put an aprx in its own folder in the first place. The suggestion to add the create folder option to the Save As menu just seemed more likely to actually happen sooner, as it would be a much simpler change than altering the aprx file structure.

AlfredBaldenweck

Save As is a curse. Don't ever use it. It is actually easier to just duplicate the entire folder in File Explorer.

Add in a duplicate Project option - Esri Community

ArcGIS Pro: Save Project Copy - Page 2 - Esri Community

RTPL_AU

@AlfredBaldenweck
NOOoooo! Please no. (with a Jesse FnF voice)

My aprx location is not in the default folder, nor is the default FGDB always in the default folder so having Pro create more folders during Save As will substantially break things for me (or just break me).

The 'new' philosophy of forcing the bundling of everything into a project folder is fit for very few scenarios, in my opinion, and most large orgs working on many projects will have data management processes that split core data, reference data, temporary processing fluff, and work product - which includes derived pdfs etc. They will also use document management and control processes that see a project (aprx) named in a specific way with incremental updates (e.g. Rev A, Rev B for planning, then Rev 1 at publication, etc).
I may also start with one aprx and then create a set of 50 maps derived from it, using the same basic resources but starting with a location plan, then all the project constraints, project designs, other context, etc (think approvals phase for large infra project).
Having a new folder for every new aprx that is filled with all the Pro incidentals is just nasty.
Ending up with 50 folders nested into the job folder adds serious potential for running into file/folder length issues with Windows or some applications - including Pro.

For me, one of the worst adaptations going from ArcMap to Pro is that moving a superseded aprx to a _ss folder now breaks things (relative paths only in 2025, yay...).
With an mxd you just save the new Rev B in the main folder and move Rev A to _ss. When you need to open Rev A in a year, everything still works.

All this means on a busy job I now already have more clutter in the main job deliverables folder than ever before. Please don't advocate to make it worse 😓

I love companies that blindly follow vendors' recommendations. They make profitable clients when someone has to step in and fix things so they can find their authoritative data again.

bdewitt_olsson

@AlfredBaldenweck, I find copying the aprx in Windows Explorer causes more problems because, if I remember correctly, it still writes the ancillary files and folders to the original folder it was saved in.

bdewitt_olsson

@RTPL_AU All I'm asking for is consistency. Like I said in my follow up comment, I would much prefer they do away with all the ancillary files. However, if the ancillary files must exist, I find it better to quarantine each aprx to its own folder to keep the mess contained.

AlfredBaldenweck

@RTPL_AU fair enough, if your workflow works for you, I won't stand in your way lol. I have personally been burned by my users using Save As to avoid having to track down their data and stuff again, and then a month or two later we're all wondering why the default folder for "Terrance_Road_Widening_2025.aprx" is "Marcus_Fishing_Outfitter_Camping_Permit", even though Terrance_Road...aprx is in a folder that says "Terrance_Road...". Super gross and probably at least half a training issue, but it makes sense to me to roll with what the program is set up to do rather than suffering the headache of fighting it, but I do see that what I suggested does not fit your needs or your workflow.

As @bdewitt_olsson says, you can definitely have trouble with moving things in File Explorer, too. There are a lot of issues that, mostly (as you say and in my experience as well) due to the reliance (insistence really), on using relative paths, as well as the very flimsy way that data sources are repaired.

I will admit I need to retract or at least amend my "Move the aprx manually" suggestion because I forgot it tends to create the index and backups folders in its current location whenever you do that and that's also a huge pain to clean up. Sorry everyone, bad advice moment.

I think if these behaviours were to be changed it would make a lot more sense to me to use Save As in my daily life. Until then, it's either duplicating the file or folder myself or a very large collection of PAGX files (which honestly might make your life easier, it sounds like, since you can launch them into a new or existing project whenever you want and they'll bring in your layouts and any maps associated with them. They also suffer the relative path problem, but resaving them is a pretty easy process).

That being said, if you make or can point me to an Idea to let us do a central place for the index folder, etc. I'd upvote it. I, too, would like to not have to see most projects' ancillary folders (except maybe backups?) in my day to day life.

Regarding moving just the aprx file itself in and out of places: If you move it from FolderA to FolderB, the paths will break. If you move it back to FolderA without having opened it and saved it, the links should work again no problem, even if you rename it. (Documented in ENH-000173491: Saving an APRX with broken data links causes incorrect fixed file paths., although the enhancement does not really reflect this behaviour properly. The case that spawned it (mine) went into detail about broken links getting transformed into broken absolute paths if saved while broken.)

Anyway, thanks for pushing back. I needed to think a little harder about what I actually do and if that's the right way. I think I'm going to get really into PAGX files in the near future.

Related Ideas:

bdewitt_olsson

@AlfredBaldenweck No worries! There's definitely no perfect solution when it comes to aprx's. Working with them is very much a "pick your poison" situation, because no matter what your workflow is there are going to be undesirable consequences. My organization has a robust data structure that our users are very compliant with for the most part, so the relative paths aren't that big an issue. I do agree though that the default geodatabase is very rarely useful. It's good as a scratch location and if you're the only person who will ever interact with your data, but individual data ownership is basically non-existent in the real world.

RTPL_AU

@AlfredBaldenweck LOL. At some point intuitive design should allow users to do the right thing, not cause headaches. We've all seen the memes on what users (myself included) are capable of 🤣

On a new job, I start Pro with a default project specified in the shortcut command line.
First task is to then specify the correct default folder and default FGDB, etc.
Then a Save As to set the correct doc control number.
Only then we slice & dice & map, etc.

The default project aprx is read-only (at a filesystem level) so no sneeze-saves can overwrite it. 😱

This is my way of preventing the scenario you describe. For me it is not just the inconvenience of having wrong names but the chance of having different clients receiving something they shouldn't.
The last thing I need is to create a package / layer file / something for Client B that still points to something from Client A. It has the potential to break trust at so many levels.
I double/triple/more check everything before I send it out but, in my opinion, with Pro you have to check everything everywhere all the time a second time. (movie sequel title?)