When exporting a submittal log on Build, users should be able to select which columns are exported onto the Excel sheet.  An existing feature allows users to check/uncheck columns in the submittal 'view' display, and even shift the order of them.  However, with these options selected, the exported Excel sheet will still display all columns in the same sequential order, regardless of what has been checked/unchecked on the 'view' display.    A new feature could also be added as an option for users to define a "standard submittal report template."  Similar to the procedure above, a standard template would allow users with Project Admin. access to set the Excel sheet displays as a template, rather than check/uncheck columns during each export.  This would be valuable to setup early in the project and export a submittal log with ease going forward.  It would also be beneficial if the Excel sheet included information within the same sheet to define the project name, date, and "submittal log."  The existing separate Excel tab (same .xlsx file) that defines this information is not beneficial for quick review during a meeting.     Overall, this request arises from ongoing issues with Contractors on multiple projects, whom are exporting submittal logs for progress meetings, and then reviewing the superfluous columns rather than the more pertinent information.  Thus, my company has had requests from both Clients and Contractors to explore the same feature as a way to save time.       Show More

Currently, Autodesk Forma Reviews does not allow notifications to be sent independently to users added under "Notify other project members".   We would like users explicitly added to this field to receive the notification for that specific Review action, even if they are not assigned to the current workflow step.   At the same time, users assigned to later steps of the Review should not receive notifications until their step is reached. Currently, enabling "Review updated" can be used as a workaround, but it generates notifications for other Review updates as well, such as comments and subsequent changes. This can result in unnecessary emails for users who are part of the overall workflow but are not involved in the current step. Requested improvement: Allow "Notify other project members" to trigger a notification specifically for the action in which those users are selected, independently from the general "Review updated" notification setting. This would provide more granular control over Review notifications and allow project teams to notify specific users when needed without generating unnecessary notifications throughout the entire Review workflow. Show More

We noticed that the title that users set for themselves in My Profile does not get pulled into variables like {contractor.contact.jobTitle}, instead their title in their Autodesk Profile is used. This is not indicated anywhere in the My Profile interface, and is not explained in the Variable Finder tool.  For now we are having to remove titles from signatures in our document templates as either the wrong title or no title is being pulled by these variables, but it would be great if the title that users set for themselves in My Profile could be used.  (We were told "this is an issue which needs resolving by the Admin team" and were asked to select the Account Admin category and resubmit here.)  Show More

Currently in a form template, only a single member/role/company can be assigned to a particular section. Typically on projects, multiple contractors and roles use the same standard template, which currently requires multiple form templates for the same activity for different companies and roles. This is very tedious on large scale with 30-50 projects and each project having multiple buildings/clusters. Each building may have separate teams, increasing the number of form templates required.    Another problem is, the contractor and the developer team, both may need to edit the same section - For example, the contractor selects Yes/No to a checkpoint and the developer want to change the yes/no selection to reject the checkpoint. This ensures structured data capture. Currently, the role/company that is not added as section assignee can only comment on such checkpoints, leading to lack of structured data which can be used for analytics in BI Dashboards.   I propose the availability of below options: 1. There should be no mandate to add a fixed section assignee in form template and can be assigned wherever fixed stakeholders are required (like Quality, safety, execution teams).  2. Option where we assign a role or company, and the user (typically contractor) initiating the form can select a user or multiple users from the assigned role or company to whom the current section shall be assigned, or next section shall be assigned.  3. Different levels of permission within section assignee - Example, the contractor role shall only be able to edit his own section, another role (developer) can be given permission to edit multiple selected/all sections to change/add any data and reject the section. 4. Permission levels for authority to submit a section - Only select roles can be given access to submit a particular section so that the contractor completes the section and selects "Completed" post which the section is sent to the role/user/company with access to submit/reject section. This will ensure step wise approval and ability to make any changes or rejection for each checkpoint within a section       Show More

Currently, Autodesk Build offers a fixed set of form template types (Quality, Daily Report, Safety, Punch List, Time Sheet, Other). While these categories cover many use cases, organizations often have additional business processes that do not fit neatly into the existing structure.   We would like the ability to create and manage our own custom template types at the account level. Example use cases: Environmental Sustainability / ESG Commissioning QA/QC Handover Design Review BIM Coordination Asset Management Facilities Management Client-specific workflows Suggested functionality: Account administrators can create custom template types. Custom types appear alongside the standard Autodesk types. Custom types can be used for filtering, reporting, dashboards, and permissions. Custom types can be managed centrally in the Account Admin settings. Existing templates can be reassigned to a custom type. Benefits: Better organization of forms. Improved reporting and filtering. Reduced reliance on the generic “Other” category. Greater flexibility for customers in different industries and regions. Better alignment with company-specific processes and standards. Business impact: As organizations expand their use of Autodesk Build beyond quality and safety workflows, the current fixed classification becomes increasingly limiting. Custom template types would improve scalability, user adoption, reporting quality, and overall data management across projects. Show More

I find the Kanban view—with its ability to sort and edit issues—very useful. It would be important to be able to display not just the four basic statuses, but all statuses available for issues: Tasks that are assigned a different status simply disappear from the list. Show More

Problem Assets are currently closely tied to the Build module, even though the Asset concept is relevant throughout the entire project lifecycle. Assets are valuable not only during construction, but also during planning, engineering, design, commissioning and operations. However, limiting access to Assets primarily to Build customers restricts their potential use in earlier project phases. This is particularly limiting in workflows where Asset information is established before construction begins, such as P&ID-driven projects, engineering databases and early project planning. Assets are also highly related to techincal resources tied to Model Management and Data Management, rather than the typichal Build personell. Opportunity Make Assets available independently of Build, either as part of Forma Data Management, Forma Design Collaboration, or as a standalone Forma Assets capability. This would allow Assets to become a common data layer that can connect information across the project lifecycle: Planning > Engineering > Design > Construction > Commissioning > Operations Assets could then be created and managed before a 3D model exists, linked to models when they become available, and continuously enriched throughout the project lifecycle. Why this matters The Asset API already provides significant potential for integrating Assets with external systems, models, documents and project data. Making Assets independent of Build could therefore turn Assets into a much broader platform capability rather than a construction-specific feature. This would also support use cases where the Asset exists conceptually before the physical or digital representation exists, allowing project teams to plan, track and validate assets throughout their lifecycle. Suggested Direction Consider making Forma Assets a platform-level capability with access independent of the Build module. This could position Assets as a core component of Forma's data model and provide a foundation for connecting engineering, design, construction and operational information around the same Asset throughout its lifecycle. Show More

Problem Today, an Asset must be created from a model in order to establish a relationship between the Asset and the model. It is not possible to take an existing Asset and subsequently associate it with a model if the Asset was not originally created as an extraction from that model. This creates a limitation in workflows where assets are defined before the 3D model exists. Challenges / Consequences Assets cannot easily exist as a planned or draft definition before modelling begins. The current workflow assumes that the model comes before the Asset, which is not always how projects are planned. In many industries, particularly process and P&ID-driven projects, assets are first defined in lists, tag registers, P&IDs or engineering databases before they are modelled in 3D. Assets defined before modelling could provide a valuable indication of what needs to be modelled. Pre-model assets could also be used to measure modelling and engineering progress by comparing planned assets against modelled/verified assets. Users may therefore be forced to maintain asset information in external systems until the model is sufficiently mature. Suggested Improvement Allow a model to be mapped to an existing Asset System or set of existing Assets. For example: Create planned Assets from a list, P&ID, engineering database or manually. Assets exist independently of any model and can represent the planned scope. When the 3D model becomes available, map the model to the existing Assets. Match model objects to existing Assets based on identifiers such as tags or other attributes. Update the Asset relationship without having to recreate the Assets from the model. An alternative approach could be to support merging Assets, for example allowing a generic or planned Asset to be merged with a model-derived instance once the model reaches sufficient maturity.   This would allow Assets to support the entire lifecycle from planning > design > construction > commissioning > operation, rather than making the existence of an Asset dependent on the availability of a 3D model. It would also make Assets useful as a mechanism for measuring the transition from planned scope to modelled and verified scope. Show More

Problem In Forma Data Management, Naming Conventions can currently only be configured after a project has been created. There is no option to define a Naming Convention at the Hub Admin level and have it automatically applied to designated folders when new projects are created. This creates unnecessary manual work, particularly in environments where many projects are created and where project creation is automated. The Naming Convention should be active from the moment the relevant project folders become available, before any files are uploaded. Challenges / Consequences Naming Conventions must be configured manually for each new project. This becomes particularly time-consuming when multiple projects are created in parallel or on a regular basis. Automated project creation workflows cannot fully configure the required Naming Convention as part of the project creation process. There is a risk that projects are created without the required Naming Convention. If the Naming Convention is not activated before files are uploaded, additional manual workarounds may be required to apply it correctly. This creates inconsistency between projects and increases the risk of files being uploaded with incorrect naming. Administrators need to revisit newly created projects to verify and complete the configuration. Suggested Improvement Allow administrators to configure Naming Conventions at the Hub level in the project template, so that the Naming Convention is automatically enabled and configured when a new project is created. Expected Benefit Hub-level configuration would reduce manual administration, improve consistency across projects, and make Naming Conventions much more suitable for automated project creation workflows. It would also reduce the risk of projects being created without the required file-naming controls. Show More

Problem Attributes can currently not be configured as Required within a project template. This means that although attributes can be defined as part of a standardized project setup, the requirement for users to populate those attributes cannot be included in the template. As a result, administrators must manually configure the required attributes every time a new project is created. Challenges / Consequences Required attribute settings must be configured manually for every new project. This creates unnecessary administrative work, especially when many projects are created. There is a risk that administrators forget to enable the required setting. Projects may therefore be created with inconsistent attribute requirements. Automated project creation workflows cannot fully enforce the required attribute configuration. Manual configuration reduces the value of using project templates for standardization. Suggested Improvement Allow administrators to configure individual attributes as Required directly within a project template. When a new project is created from the template, the configuration should be inherited automatically. Expected Benefit Allowing Required Attributes to be defined in project templates would improve consistency, reduce administrative effort, and ensure that standardized project requirements are applied automatically to every project created from the template. Show More

It would be beneficial if a series of additional questions would be prompted to the user for completion pending on the dropdown response selected. For example, if "XYZ Company" selected, then questions 1.1-1.5 are required but if "Other" is selected, then no further action is required and question 1.1-1.5 are not required for completion.  Show More

In Project Admin > Members, the Role dropdown has a fixed width, so longer role names are cut off with an ellipsis. Roles that share a prefix then display identically, and the only way to tell them apart is to hover each one and read the tooltip. The full name is already in that tooltip, so the data is there. Please size the dropdown to the longest role name, or wrap onto a second line, so it can be read without hovering. Show More

Make it possible that, on a HUB level, no trial version for cloud licenses (f.e. Data Management) can be activated by users. If you have a HUB under EBA contract, then no user should be allowed to access trial versions of products. They should only access products that they are assigned through commercial licenses. Show More

Problem References to deleted objects in Autodesk Forma can remain visible and cannot be removed. For example, a File Package may be referenced from an Asset in an Asset System. If the File Package is deleted before the reference is removed, the reference can remain visible on the Asset even though the referenced object no longer exists. The current behavior requires users to remove all references before deleting the referenced object. In practice, this requires a level of control and coordination that is difficult to maintain, particularly in larger projects and environments with multiple users. Challenges / Consequences References can remain visible after the referenced object has been deleted. Users cannot remove the remaining reference from the Asset after the deletion has occurred. Deleted File Packages cannot currently be restored, leaving no apparent way to recover from this situation. The sequence of actions becomes critical: the reference must be removed before the referenced object is deleted. Suggested Improvement Allow users with appropriate permissions to remove  references from an Asset or other object, even when the referenced object has been deleted. The system could identify these as broken references and provide an option to remove them. Deleted referenced objects should  be recoverable for a defined period, allowing users to restore the object or clean up its references before permanent deletion. (such as files). Show More

Hi, In precon module, in Takeoff, for 2D sheets, we can load 2D documents coming from data Management. For 3D models, it will be great to have the same, not loading 3D models coming from computer.   Thankz Show More

Currently, the only way in which Key Reviewers can approve documents in a review workflow using the Revies tool is via comments. This method often causes confusion, particularly for users with no prior experience using Autodesk Forma, and comments indicating approval, rejection or approval with comments tend to get lost amongst the document’s comment threads, mark-ups or general comments on the steps of the review workflow. It would be useful to have a drop-down menu allowing users to simply select either ‘Proposed for approval’ or ‘Proposed for rejection’ for each document. The final reviewer could then use these references to finalise the workflow. Show More

In the whiteboard, you can view project tasks and create new issues. It would be helpful if the issues created there were linked to the whiteboard, so that when you follow the link in the notification email, you are taken directly to the whiteboard. Show More

Problem Issues in Autodesk Forma are automatically assigned a title based on the selected Issue Type. This often results in issues being created with generic titles such as “Design” or “Design Review”, simply because these are available Issue Types. Although the Issue Title is configured as a required field, the automatic title means users rarely replace it with a meaningful description. As a result, the Issue Title often becomes little more than a duplicate of the Issue Type. There is also an inconsistency when users change the Issue Type during issue creation. For example, a user may initially select Design Review, resulting in the title “Design Review”, and then change the Issue Type to Design. The resulting issue can therefore have: Type: Design Title: Design Review This creates misleading or inconsistent issue information. Challenges / Consequences Issues become difficult to distinguish from each other in lists, reports and dashboards. Issue titles provide little additional information beyond the Issue Type. Users have to manually correct automatically generated titles. Changing the Issue Type during creation can result in mismatched Type and Title values. Generic titles reduce the usefulness of issue data for reporting, filtering and downstream workflows. Large projects can quickly accumulate hundreds or thousands of issues with repetitive and non-descriptive titles. Suggested Improvement Consider changing the default behavior so that the Issue Title is initially blank, even when Issue Type is selected. Alternatively, the Issue Type could be used as a placeholder rather than automatically populating the Issue Title. The user should be encouraged or required to provide a meaningful title that describes the actual issue. If automatic title generation is retained, the title should at minimum be dynamically updated when the Issue Type changes until the user has manually edited the title. Expected Benefit Separating Issue Type from Issue Title would make issue data more descriptive and consistent, improve usability in issue lists and reports, and reduce the amount of manual correction required from users. Show More

Hi,   The symbol detection doesn't really work, even for simple elements (sanitaries, doors...). it miss 90% of the symbols, it could add some item in empty area... Maybe need specific option / tickbox as sentivity, ignore color, you select a symbol and you can modify a bit the image, do detection inside a specific area... I have the feeling, it doens't understand the rotation of the elements... Blubeam or similar softwares are better for this topic. Thankz Show More