Everyday OperationsLast updated: 6 August 2026

SFS Access is designed to work with normal ExpressionEngine file field output, so day-to-day publishing can stay close to the standard EE Files workflow. The main difference is that file URLs for enclave-controlled locations are routed through SFS Access so access is checked when the file is requested.

In practice, that means most common file field output patterns continue to work:

Simple file URLs — file field output can still be used as a direct URL in templates.
Link and image wrap output — wrapped file output continues to work and is secured through SFS Access when the file belongs to a protected enclave.
Tag pairs — file metadata such as file name, file size, file type, width, height, title, and upload date still render as normal.
Image variants — manipulated image URLs continue to be supported, including common responsive image patterns such as srcset.

When a file belongs to an enclave-controlled upload location, SFS Access rewrites the visible file URL to a short-lived secure stream link. The user still sees a normal link or image in the page, but the file is delivered only after SFS Access checks the member’s current access at request time.

This is what makes SFS Access suitable as the base product for secure file delivery in the SFS suite. Companions such as SFS Vault, SFS Gateway, and OTP Pro add extra capabilities around encrypted storage, external sharing, and step-up validation, but the everyday file field experience remains familiar.

What content teams can usually expect

They can keep using file fields in ordinary EE templates without learning a new publishing model.
They can copy or share the secured URL if needed, but the link still depends on current access rules when it is used.
They should expect a blocked file request to fail cleanly if access is no longer allowed.

Plain text file URLs

By default, SFS Access rewrites file URLs when they appear in supported HTML attributes such as links, images, poster tags, and srcset entries. It can also rewrite plain text file URLs in rendered HTML when the optional plain-text rewrite setting is turned on.

This is useful when a file URL is shown directly in body copy or other visible text. If the setting is enabled, SFS Access will turn that visible URL into a secure stream link in the final page output.

Plain-text rewriting is optional because it is broader than the default attribute-based rewrite path. It is best used where you want a fuller drop-in experience and you are happy for visible file URLs in rendered page text to be secured in the same way as link and image output.

What SFS Access does not change

It does not change how content teams select files inside EE.
It does not change the file field type itself.
It does not make file access “public”; the access check still happens when the file is requested.

For most sites, the everyday rule is simple: if a file field output ends up on the page for a protected enclave, SFS Access will usually secure it without the content team needing to do anything special.

Common Admin Tasks

Day-to-day SFS Access administration involves a small set of recurring tasks. The following covers the most common ones and what to check as you work through them.

Adding a new enclave

Confirm the intended upload location is above webroot and available in EE Files.
Confirm Secure Root settings and health status if location creation depends on that path.
Assign the enclave to the correct eligibility pool.
Set role permissions before assigning members.
Use Effective Access Check to validate outcomes before notifying users.

Assigning a new member

Confirm the member is already in the relevant eligibility pool.
Assign the member to the enclave with the appropriate role.
If prompted, complete OTP verification before the change can be saved.
Verify effective access before communicating the change.

Removing or adjusting access

Deactivate the membership for the relevant member and enclave.
Confirm role permission changes are saved where required.
Confirm via Effective Access Check that the change has taken effect.
Review the Security Activity Log to confirm the transition is recorded.

Using Effective Access Check in practice

Select enclave and member.
Review allow and deny outcomes by operation.
Use reason codes to decide the next corrective action.

Supporting Content Teams

Content teams working with secure enclaves should not need to think about policy internals. SFS Access is designed to let authorised users complete file tasks in a familiar EE workflow, while unauthorised actions are predictably blocked.

To support your content team well:

Set expectations clearly when access is granted — tell users which enclaves they should be able to see and what they are allowed to do there.
Do not disclose hidden security scope — users should not be briefed on enclave names or structures they are not expected to access.
Explain what blocked actions look like — when a user is denied an action, the outcome is consistent and policy-based. Reassure users that a denial is not an error and how to report unexpected access issues.
Provide a clear contact for access queries — a named person or channel for permission requests reduces informal workarounds and keeps access control tidy.

Teams that understand what they can do, and what to do when something does not work, need less ad hoc support from administrators.

Change Management Tips

Permission changes can have an immediate effect on who can work in which enclaves. Handling these changes carefully reduces disruption and maintains trust in the governance model.

Make changes in a staging environment first when possible, especially for broad permission updates or new enclave configurations.
Use Effective Access Check before and after changes to confirm the outcome matches your intention.
Communicate planned changes to affected users in advance, particularly when access is being reduced.
Keep changes small and targeted — adjust one enclave or one member at a time rather than making multiple changes simultaneously. This makes it much easier to identify the cause if something does not work as expected.
Review the Security Activity Log after changes to confirm the transition is recorded as expected.