City of Waco Accepts Bid Files on Files.com Without Creating Bidder Accounts or Opening SharePoint

The City of Waco governs roughly 145,000 people on the I-35 corridor between Dallas and Austin, and its reach runs well past the city limits. It wholesales water and wastewater treatment to the communities around it, operates the public health district for every city in McLennan County, runs a regional airport, and co-manages a National Park Service monument. A government that operates all of that buys constantly: construction, equipment, engineering, services.

And it buys in the open. The Purchasing department publishes bid and contract documents for anyone to download, and any vendor, including one the city has never dealt with, can submit a response. Every solicitation is a file exchange with the public: documents out to whoever wants them, responses back from whoever chooses to answer. That is the exchange the city's own collaboration platforms turned out to be structurally unable to carry.

The Guest Account Waco Could Not Create

Waco's estate is Microsoft. When city staff exchange files with a known outside party, IT creates a OneDrive guest account for that person and shares the material to it. The model works because the city knows who it is dealing with.

Public bidding breaks the model at its first step. A guest account has to be created for a named person before that person can touch a file, and the entire point of an open solicitation is that the city does not know who will answer it.

“You don't know who's going to submit these. They're just going to submit or not submit, so if there's no guest account created for them, they can't really do that with the system we have.”

Purchasing had no sanctioned channel for bid packets that anyone must be able to pull and responses that strangers must be able to push.

SharePoint Ruled Out by Policy, a City-Run Server Ruled Out by Risk

The obvious alternative was SharePoint, and the city ruled it out. Security policy did not allow the SharePoint site to be opened to external users.

The other route was to build it: stand up an SFTP server on the city's own network and let the public upload to it. IT rejected that on risk.

“If we create an SFTP server on-site and allow every stranger that wants to put files in a repository, you could have a problem with malware.”

By then the requirement had a precise shape. Publish documents to anyone. Accept uploads from anyone. Create no accounts, because there is nobody to create them for. Carry the city's own name, keep the staff side governed and logged, and put none of it on the city's network.

Waco put that exchange on Files.com. For John Branch, the IT manager who owns the platform, the capability that made the workflow possible was the upload link itself: send anyone a link, and they can submit files through it.

Bid Packets Out, Responses In, Nothing on the City Network

For each solicitation, Purchasing publishes the bid and contract documents through Files.com download share links. Anyone with the link opens it in a browser over HTTPS and pulls the packet. Responses come back through Files.com upload share links, which place each submission into folders Purchasing controls. No bidder ever holds an account, so there is no provisioning step to perform and no credential to clean up afterward.

The links run under the city's own .gov domain with SSL, so a vendor responding to a Waco solicitation sees the City of Waco, not a third-party tool. And because the public touches only the hosted Files.com surface, nothing in the workflow terminates on the city network.

The staff side is a different world, deliberately. City employees sign in through single sign-on against Microsoft Entra ID, accounts are provisioned and deprovisioned from the directory over SCIM, and second factors are enforced. Folder- and file-level permissions decide which staff reach which material, and every access and download lands in the activity log. That asymmetry is the design: anonymous on the outside, directory-governed on the inside, one platform holding both.

Public Bidding With Nothing to Provision and Nothing to Patch

With share links carrying procurement, Waco replaced a workload that had no workable path with a standing pattern:

• Vendors and the public download bid documents and submit responses with no account created for them. The per-bidder provisioning step is not automated; it is gone, because there is nothing to provision.
• The city's SharePoint stays closed to external users, exactly as security policy requires, while public bid distribution happens anyway.
• No internet-exposed intake server sits on the city's network. The malware and zero-day surface an on-site public repository would have carried was never built, so it never has to be patched, monitored, or defended.
• Each new solicitation costs Purchasing a set of links its own staff create. Opening the next bid to the public is not an IT project.

Open Procurement Without an Open Network

Identity-based platforms assume the city knows who is coming. Open bidding assumes the opposite. Waco did not resolve that by loosening anything. It kept its Microsoft estate exactly as sealed as policy demands and put the public exchange on a layer built for strangers.

Today, a contractor who has never done business with the City of Waco clicks a link on a solicitation, reads the packet, and uploads a response, and nobody in city IT created an account, opened a port, or patched a server to make that possible. Before Files.com carried the workload, that vendor had no sanctioned way in at all. A government whose collaboration tools all require named users can still trade files with people it cannot name. The answer was never to weaken the identity boundary. It was to put a governed, hosted doorway outside it, and Files.com is that doorway.