The AL files autogenerated by the BC Sandbox page designer could use some fine-tuning. For example, I redesigned page 951 (Time Sheet List) and added a couple of base fields to the page. The .al file in the designer .app that the sandbox produced had several discrepencies: Why did the object numberings start at 50100? It's to my understanding that SaaS tenants have unfettered access to object IDs 50000..99999 In this case, the .al file produced was PageExtension50100.al. After bringing that file into VS code I renumbered and renamed the file to "PagExt951-Ext50000.ATL Time Sheet List.al" in accordance to MS's best practices (ATL in this case is the prefix I chose for this particular tenant). I think the sandbox page designer needs to be smarter than this when generating page designer apps. 1) start at object ID 50000 (no idea why it needs to start at 50100) 2) the designer should prompt for a short prefix when saving the page changes to a desiger app. If the prefix + base name is too long for VS Code (30 characters I think?) then truncate the trailing characters in the object extension name). 3) name and number the underlying .al files in the zip accordingly (example see above). 4) any fields added to to a table or page extension should be auto-prefixed in accordance to the prefix entered @ design completion. 5) Auto-format the .AL files in accordance with VS Code's AL formatter (currently, the two have indenting differences). All this combined would result in reduced manual .al file rework in VS Code.