Wishlist

There are almost 1000 wishes in this forum. Many of them would be obvious improvements - making the software more functional, intuitive, integrated, and dynamic.

Instead of waiting for TWO HUNDRED people to express dissatisfaction on this forum, how about somebody from Graphisoft regularly reviews the wishes for what are almost objectively good ideas and works to get them on the roadmap and into the software?

I've been on this Wishlist since it was created and there's a lot of gold in here. I don't know that we deserve compensation for these wishes as another user has suggested, but I would like all of the good ideas we are putting forth to actually help improve the software.  I know wishes are moving to "Under Consideration" with 20, 30, 40 upvotes. I'm just saying can we restructure this a little?

The community provides good ideas -> Graphisoft reviews *ALL* of them -> The good ones get incorporated, *especially* the ones with many upvotes.

Would anyone else like to see more than a handful of these ideas get into the software?

EDIT: (moving this from a comment into the post)

I think part of what is happening is that the Wishlist forum is fielding both Wishes with a capital W ("wouldn't it be cool if Archicad could ___"), and User Experience feedback ("this tool isn't working as expected", "there are inconsistencies in your interface", "I'm not able to ___ when this happens, but it works everywhere else", "in your latest update, you lost this feature").

There is so much UX feedback - we have essentially become a global UX team, which on the one hand is great - we use the product day in and day out and can easily notice when the experience isn't meeting par. The key is that Graphisoft needs to sort out which "wishes" are aspirational and which are essential. As a daily U, this would greatly improve my X.

As the project files in Archicad can get quite big pretty quickly (100-1000MB) and not all Projects require a Teamwork file, it would be very useful if the saving process could be done in the background (as for example Photoshop does it, or as the Teamwork Snapshots work as well) so that we could continue working and not have to wait these precious seconds It's even more useful in home office scenarios, where the office VPNs can have a bandwidth limit imposed, or if the internal office server is old/slow.

Of the 3 publishing methods, to create:

• Flat file structure -> shows exported file location
• Folder structure -> shows exported file location
• Single file --> Does NOT show exported file location

Instead, the success dialog box is effectively redundant/useless as it displays no new information. It repeats what is already shown by the green checkmark and in the status column (see screenshot).

Archicad currently does not support saving and working on solo .PLN files directly within cloud-synced folders such as Dropbox, Google Drive, or OneDrive. The save operation generates temporary and lock files that conflict with real-time sync clients, creating a race condition that can result in save failures and, in rare cases, file corruption.

This is not a niche edge case. The majority of small and mid-size architecture firms in 2026 use cloud storage as their primary file management infrastructure. Telling users to avoid cloud-synced folders and instead work locally then manually copy files is not a realistic workflow. It introduces human error, breaks version continuity, and contradicts how every other professional desktop application in the industry operates. Adobe, AutoCAD, Vectorworks, Microsoft Office all handle cloud-synced folders without issue.

The request is straightforward: implement a save mechanism for solo .PLN files that coordinates with cloud sync clients, either by pausing sync during the save sequence, using atomic write operations, or adopting a save architecture compatible with how modern cloud storage hooks into the OS. The technical pattern is well established across the industry.

This is not a nice-to-have. For firms that rely on Dropbox or Google Drive as their file backbone, which is most small firms, this is a fundamental reliability gap that creates real data risk daily.

BIMcloud SaaS tenants are assigned to a Google Cloud Platform region based on country of purchase, with no option to select or request a different region. Graphisoft's own documentation acknowledges that latency directly impacts Teamwork performance, particularly Send & Receive operations, and directs users to verify their latency using GCPing.com before committing to SaaS. Reference:

https://community.graphisoft.com/t5/Teamwork-BIMcloud/BIMcloud-Software-as-a-Service-Connection-Test...

We followed that recommendation. The results, measured from Costa Rica using GCPing.com, show the following:

São Paulo (southamerica-east1), which is the assigned region for Costa Rica: 180ms South Carolina (us-east1), the best performing region from our location: 85ms North Virginia (us-east4): 93ms Dallas (us-south1): 108ms

São Paulo is not only the worst performing region in the Americas from Costa Rica, it ranks on par with European cities including London, Madrid, Paris, and Belgium. It performs worse than every US region by a significant margin, and it is geographically further from Costa Rica than multiple US options.

Graphisoft's own network requirements documentation states that slow round-trips significantly affect operations requiring multiple packet exchanges between client and server, specifically naming Send & Receive. At 180ms base latency, every Teamwork operation accumulates this penalty across multiple round-trips, making daily Teamwork use genuinely impractical.

Notably, Graphisoft does not publish a maximum acceptable latency threshold anywhere in the connection test documentation. Users are directed to check their latency without being given a pass or fail benchmark. This means firms in affected regions can unknowingly purchase Collaborate subscriptions, complete the recommended connection test, and still have no basis to evaluate whether their assigned region is acceptable.

The request has two parts.

First, publish a clear maximum acceptable latency threshold in the connection test documentation so that firms can make an informed purchasing decision before committing to a subscription.

Second, allow tenant region selection at purchase, or at minimum allow firms to request reassignment to the lowest-latency available region. Locking tenant assignment to country of purchase without any recourse is not acceptable when the assigned region demonstrably fails to support the product's core workflow.

This affects all of Central America and likely other Latin American countries facing similar routing. It is a verifiable, measurable infrastructure gap that makes a paid feature non-functional for an entire region, and it directly contradicts the product promise of seamless cloud collaboration regardless of location.

The Autotext function is really useful for labeling. You can use it to label everything from date to drawing name to properties. We propose that Autotext can be placed wherever in your PLN and actually be exported to DWG while keeping the value it displays in Archicad. 

Dear All, 

I would like to bring here a topic about critical backup license infrastructure.

Currently the Emergency license system works well, however only for Archicad and BIMcloud (on-premiss). 

When someone has an issue with the Cloud Collaborate License the current Emergency license works only for access to Archicad > NOT BIMcloud SaaS ! 

This brings a situation when the user with Emergency license can't work on his/her project on BIMcloud SaaS.

Provide a bug tracker that allows the public to access bugs including their ids, descriptions and progress. It is currently not possible to review this information except through maybe manually messaging support, but even then information is limited. This creates a lot of problems for users and testers wanting to keep track of bugs, and learning whether a bug is acknowledged or not. It creates a lot of unnecessary confusion and communication in favour of a closed system. Instead, Graphisoft should look to how open source projects handle their bug tracking - such as with GitLab.

When attempting to select one from amongst a number of overlapping elements in plan view (such as fills, slabs, roofs, library objects etc), hitting the <Tab> key while the pointer hovers above them, will normally cycle between and highlight each element in turn beneath the pointer, without the need to chance exactly on a node or hotspot, and the user can just keep hitting <tab> until the correct element is selected. 

However when the overlapping elements are large enough to extend beyond the current zoom in the plan view window, especially when there are complex elements (such as site meshes) in the mix, ArchiCAD often takes a longer time to identify the overlapping elements, and the Tab-between-elements behaviour appears to time out, leaving the fallback MS Windows OS Tab-between-fields behavior to kick in (apparently this issue does not arise on Mac) 

So, instead of tabbing between elements in the normal way, when any of the overlapping elements are too complex or large to be detected in time, suddenly, hitting Tab causes the focus to switch away from the elements under the mouse pointer, to the feilds in the Tracker dialog nearby.  

Currently, the onlywork around I have found is to ensure Tracker is not enabled.

I reported this to Central Innovation, my local reseller, but they are adament that Graphisoft has told them that this irritating and intermittent behaviour is intended, or 'by design'. 

In other words, 'by design', it affects only Windows computers, and 'by design' it affects only views where the overlapping elements are large or complex, and 'by design' it only occurs when Tracker is enabled.

My only scope for having the bug corrected, they told me, is to post it as a 'wish'.

To me, demoting bugs to 'wishes' rather than owning up to and addressing them, is just more evidence of the Graphisoft corporate cash-grab decline - however I am now posting it here.

The performance of section and elevation views is extremely bad (slow), especially with shadows turned on and ('many') objects used.

It should match the performance of the floorplan display or the 3D window.

Especially the very slow update of these views on layouts kills all submission deadlines.

Customers need a means of accessing and converting old Archicad projects other than keeping an old computer running an old OS sitting around "just in case".

As is usual, Graphisoft only provides compatibility updates to the current and previous release of Archicad (two versions).  This has worked fine in the past when all versions of Archicad could open old projects, however now we have a situation where only AC 26 and earlier can open projects from version 16 back to as old as version 8.1 ... and so if Archicad 26 cannot run, then those old projects are inaccessible with current Mac operating systems.  See the macOS Sequoia KB article:

https://community.graphisoft.com/t5/Installation-update/macOS-15-Sequoia/ta-p/616173

and the file compatibility article:

https://community.graphisoft.com/t5/Licensing/Archicad-file-and-protection-compatibility/ta-p/304085

For many years, Graphisoft offered a special Archicad 10 "converter" version download that could open projects back to version 6.5 ... but that converter version is no longer compatible with macOS either.  Thus, Mac users will very soon find themselves with no means of opening old projects, rendering their intellectual property inaccessible if those projects were never (tediously) migrated to a modern version.

This wish is for Graphisoft to maintain macOS compatibility for Archicad 26 indefinitely as a "converter version" for old projects... and/or to offer a compatible converter version similar to the old AC 10 converter. 

PS. Even Archicad 28 can open files back to version 17 - so this wish only impacts users who have been customers for longer than 10 years.

Problem: Graphisoft released MEP tools on 2024-09-30 which completely replaced previous MEP object functionality. This removed a functioning tool and replaced it with a non-functional tool. We are not paying for half-baked alpha-level features to be implemented in a software release when a fully functional tool is already in place. Developers at Graphisoft: You know this implementation doesn't work better than what was there before and if you don't know that then you shouldn't be a developer. Whoever made the decisions to implement this broken implementation into a release should be fired.

The new tools are clumsy and buggy at best and useless at worst.  As of this date the MEP modeler still has no straightforward ability to simply slope a pipe (the slope input exists but is non-functional.) That should be a primary function. As a US user, there are no route specifications for common US pipe sizes, no standard fittings that plumbers actually use, no ability to schedule pipe runs or fittings with real data, the branch tees do not function correctly, and if I want insulation I'll select it, don't enable it as the default, that is not helpful for piping (don't treat a duct like a pipe).

Simply put: Fix this nonsensical, half-baked, lame excuse for an implementation that suffers at all levels. In essence, my 'wish' is that you stop sh*tifying your software and increase the price while doing so. Just get back to Graphisoft's statement of "software designed by architects for architects." The developers or at least those that manage them need to understand actual professions of architecture and building construction, not just software.  

The Grasshopper connection is currently limiting in the sense that information can be read from Archicad, but only Geometry sent/created through the link can be adjusted.

It would be amazing if such a basic thing as having full parametric control over a model or parts of it would be possible. Sometimes it's really just about updating some parameters or properties in Archicad, not necessarily about the geometry.

One example here:

Re: Use Object from library returns Null - Graphisoft Community