An Energy Program Implementer Makes Temporary External Access the Default on Files.com

An energy-efficiency program implementer designs and runs demand-side programs on behalf of utilities. Its work brings together employees and outside partners who need to exchange files for the life of each program.

Every one of those programs is temporary by design. A utility commissions it, the firm staffs it with its own people and outside partners, and eventually the program winds down. The file exchange behind the work follows the same rhythm. Each program brings contractors, partner firms, and utility staff who need to move files, and each program eventually stops needing them. A business built on engagements that start and end on someone else’s schedule can never have a stable population of external users, so the firm was always going to face a question most companies never have to ask at this scale: who removes all that access when the program ends?

A Partner Population That Swings With Every Program Cycle

The company’s VP of Technology has described the pattern as random by nature: a program team decides the exchange is its solution, needs twenty users for six months, and then the program ends. By that account, user growth is not something the company will ever be able to predict.

Arrivals are easy work, because creating an account is simple. Departures are the design question. When a program closes, its accounts have to close with it, and the company wanted that to happen by rule rather than by request. The exchange had run on a self-hosted FTP server, where an account existed until an administrator deleted it, and the company wanted the platform that replaced it to carry each account’s end date from the start.

Any removal process has to keep pace with structural churn. Turnover is driven by program starts and ends across many concurrent engagements, on schedules set by utilities and regulators rather than by IT. The only process that scales with the number of programs is one the platform runs itself.

Making Expiration the Default State of an Account

The fix had to invert the default. An account had to carry its end date from the day it was created, so that removal happened by policy. Access had to attach to the structure of a project rather than to individuals. The live population had to be verifiable against real logins. And all of it had to be workable in bulk, because users arrive twenty at a time.

The firm selected Files.com as its client and partner exchange and wrote those requirements into platform policy. Files.com became the layer that ends access, so that no person has to.

Every account on the site was created with an expiration date. Alongside it, Files.com’s inactivity rule disables any account that has not logged in for a set period. The two policies cover both ways a program-scoped user goes stale: the engagement running out, and the person quietly stopping work before it does. Either way, Files.com closes the access on its own.

Access itself was granted only through Files.com security groups, never to individuals. A single project can carry many groups across its nested folder tree, keeping access legible by program: reviewing a project’s access means reviewing its groups rather than hunting through individual grants.

For the volume, the team scripts against the Files.com REST API. PowerShell jobs driven by CSV files create users, assign them to groups, and update enable and expiration flags in bulk when dates need to change. Standing up a program’s twenty users is one pass rather than twenty tickets. Files.com’s last-login reporting then shows who is actually active, turning periodic access reviews into checks against data.

Access That Ends by Rule

With those policies in production, the firm runs access that ends by rule. Program-scoped accounts reach their expiration dates on schedule, while accounts that go quiet are disabled automatically. The gap between a program ending and its access ending is bounded by policy.

Periodic reviews now confirm the policy against last-login data instead of performing the cleanup themselves. When the next program begins, its users are created, grouped, and given end dates in one bulk pass, so growth in programs does not mean proportional growth in administration.

Governed for the Programs Nobody Has Predicted Yet

Today the population still swings the way it always has. Programs keep starting on utilities’ schedules and ending on regulators’, and the firm still cannot predict its own user growth. What changed is that the unpredictability is not a governance question. Every account on the Files.com site is born with its end date, and the ones that go quiet are shut off before anyone asks. The firm did not get control of external access by predicting the churn. It made prediction unnecessary: on Files.com, temporary is the default state of an account, and a program that ends takes its access with it.