Target a document at the smallest appropriate group of records, rather than a separate list of email addresses. Use project-wide access for everyone, a selection of records for a target group, and category or form context for documents belonging to one part of a process.
Document access becomes unreliable when employees manually select people for each publication. People change; records remain. Link visibility to the object that represents the business relationship.
Choose the scope before uploading
Yindle Portal can display a document project-wide or restrict it to a list of units or records. A file can also be attached to a category or questionnaire. Customers only see documents within the scope of their own records.
First ask the uploader who the document is intended for. The file and title come afterwards. A safe default is not automatically “everyone”; choose the most common appropriate audience and display it clearly before publication.
Use groups with a meaningful purpose
A selection such as “records 12, 14, 18 and 23” is difficult to maintain. Record the reason: home type B, participants in the June cohort or customers with the Plus service package. If the source for that group is elsewhere, consider an integration or controlled import instead of maintaining it manually in two places.
When a record closes or a new customer gains access, recheck which documents remain visible. Record access and document scope should follow the same lifecycle.
Worked example: a fictional housing association
In this fictional example, housing association Stadshaven shares a general schedule with every resident in a complex. Balcony glazing instructions apply to only twenty homes. An individual appointment confirmation belongs exclusively to one property's record.
The content manager selects the appropriate scope for each file and checks a resident preview before publication. When a resident moves out, their relationship to the record ends; the team does not send separate withdrawal emails for each file.
Use the audience check
- Purpose: which customer task does the file support?
- Scope: everyone, a recognisable group or one record?
- Context: general, category-specific or tied to a particular form?
- Duration: when does access start and how long is it needed?
- Owner: who replaces or withdraws the document?
- Check: which two previews establish that the scope is correct?
Alongside the intended preview, run a negative test: open the portal as a customer outside the target group and check that the title, search result and download route are not visible.
Prevent leaks through related channels
Correct portal access is not enough if a notification email sends the filename to the wrong group or a direct download link fails to recheck authorisation. Test the dashboard, document list, search, email and URL separately.
Also maintain a simple publication list containing the document, scope, date and owner. Use it for periodic reviews, not as a second source of access permissions. The application remains authoritative.
Test group changes explicitly. If a record changes from home type B to C, access to old type-B instructions should disappear when they are no longer needed. At the same time, an earlier decision may need the old document as evidence. Separate current availability from historical references in the internal record.
Watch for derived files. A thumbnail, preview or extracted text falls within the same scope as the original document. Securing the PDF achieves little if a search index reveals a sentence to unauthorised people. Include every generated form in the access review.
For bulk publication, a preview with counts is useful: “This file will be visible to 20 of 60 records.” Have an administrator check a few names or record codes and request confirmation for an unusually broad scope. That extra step prevents a costly publication mistake.
Finally, discuss how customers can report an error. A “this document is not meant for me” button can provide a quick containment route without the customer forwarding the file by email. If a scope problem is confirmed, revoke access, investigate the logs and follow the agreed incident process.
Include a user with multiple records in the acceptance test. A document intended for record A must not appear through recent downloads, browser history or a search result for record B. Check this again after an audience, project relationship or file version changes.
Explore the document and record features in Yindle Portal and read about the approach to a own customer portal. To create an audience model, map out three document types with Yindle.