Feature RequestsCRM Opportunity ID in New Project
Add an Opportunity ID (CRM #) field at the top of the New Project dialog, above Workspace, connected live to the CRM (via a API/mcp) that you can text search to find our project quickly. Selecting an opportunity auto-prefills Project Name, region, industry, location and other fields we can map to as needed. It needs to go at the TOP, shown below.
Every GC and trade partner already tracks pursuits by an opportunity number in their own CRM. Re-keying that data into takeoff creates typos, naming drift, and no way to tie a takeoff back to its pursuit. This needs to be a global setting any workspace can add too. We have this setup in Ediphi already...without the prefilling tho.
This brings us full circle back to the core problem I keep bring up. One project to many takeoffs is not something we can do consistent across all GC's & Trades in zzTakeoff yet either. This is a core data structure issue.....now in zzTakeoff we will have many CRM numbers for many zzProjects since we make multiple projects for each major set in zz. SD/DD/CD ect. (Example below)
Hey Kyle, thanks for the feature request! I've let the team know about this. In the Ediphi implementation, do changes from your CRM automatically sync to Ediphi, or do you need to re-select the opportunity?
Regarding the 1 project to many takeoffs issue. We're discussing solutions internally and deciding on the best approach. 🙂
Kyle, I 100% agree with you here.
This feels like relatively low-hanging fruit from a software architecture standpoint for zz — although maybe I'm underestimating it.
It seems the basic hierarchy should be:
1 Project → unlimited Versions / Iterations
The project maintains one primary identifier throughout its life. Underneath it, we should be able to create essentially unlimited iterations. One is the current labeled the WIP (current working version); the others are historical versions that can be locked but reopened, duplicated, compared, or resurrected at any point. The WIP can be reassigned because some times we have many options, we go down one path ... then reverse and go back to one of the other original options and go down that different path. All of these should be able to tag design development maturity to them.
Today in zz, I accomplish this by duplicating the entire project and changing the name. It works, but I don't think that's the right long-term architecture.
For a large GC doing preconstruction from napkin sketches through design development, tender and ultimately buyout, a single project can go through 5–20+ meaningful iterations over several years. I actually have one project that started in 2014 and is still ongoing — 12 years in preconstruction, which might be a record for us.
I've raised a similar issue (although very different) with Autodesk. Their architecture has traditionally treated estimating as a single entity with a linear process: you're current work is always working in the current WIP & you are able to save snapshots along the way. Duplicating projects is trick (in zz its great). The with problem Autodesk is that those snapshots become almost "ghosts" of the estimate at that moment. They preserve some of the data, but we loose a lot of the context and aren't really working versions that you can manipulate, branch from, or bring back to life. I believe they're working on improving that.
I think zz has an opportunity to handle this much better. I love how easy it is to duplicate projects ... but these projects need to be able to be rolled up in a parent project and then connected to MCP as Kyle indicates.
With the current zz set up ... when we scale up, we'll be adding hundreds of projects per year, each potentially containing 5–20 iterations. We don't want that turning into thousands of artificially duplicated "projects" every year causing chaos.
The project should remain "the project". The iterations underneath it should represent how that project evolved over time.
I think we're very close here — we just need to push this one over the finish line.
Savvy Kyle?
@Lorin,
Amazing you have this one-to-many in your crosshairs! (PS hit me up to walk thru how Ediphi has it setup, they have it dialed and I love the fact that is a global settings for all GC's...kind of nice when software can herd the cats)
To your question about refreshing the data from CRM to xyz. When a person in our marketing marketing adds a new job in CRM (we use Microsoft Dynamics), boom it shows up instantly in Ediphi, as we have a API call going. What we dont have is auto-populating fields in Ediphi (they are working on it tho). I would imagine in zzTakeoff we could configure this to be either a one-time pull and then the user can edit it, or a option to have this syncing, so when it changes in CRM it changes in zzTO, which would be the dream.
@ Aaron
Love your input and 100% agree.