Skip to content
Portal development

A clear place for people to access the work that concerns them.

FSS develops portals for UK charities and faith organisations that need members, parents or staff to complete tasks and see relevant information. The starting point is who needs access, what they need to do and which records they should be able to see.

By Faithful Software Solutions · Updated

Give repeated requests a defined route.

A portal can suit teams handling registration, document requests or updates across email and spreadsheets. Map those tasks before adding a new place for people to sign in.

Make the next action understandable.

The intended result is a usable route through each task, with clear status and an identified person responsible for follow-up.

  • Accessible onboarding and account recovery
  • Information and actions scoped to each role
  • Clear submitted, pending and completed states

Portal work in NexSteps.

NexSteps includes role-scoped access, support portals and parent onboarding. FSS built these alongside its safeguarding, attendance and operational workflows.

Permissions and integrations shape the scope.

The number of roles, identity requirements, existing records and any billing or document workflows affect the build. Agree the account lifecycle and support needs before setting the delivery scope.

Access needs deliberate design.

Define how access is granted, reviewed and removed. Test permissions and account recovery, and decide what happens when someone leaves or needs help completing a task.

A clear path from problem to working software.

  1. Understand and scope

    Map the people, workflows and constraints. Agree what success looks like before committing to a build.

  2. Build and review

    Work through a defined scope with working updates, explicit decisions and review points for your team.

  3. Launch and hand over

    Plan migration, testing, documentation and support so the software can be operated and maintained.

Frequently asked questions

Can different people see different information?

Yes. Roles and permission boundaries should be agreed during discovery and tested against the actions and records each role needs.

Can a portal connect to our current systems?

That depends on the systems’ supported interfaces and data access. Reviewing these is part of scoping, before promising an integration.

Does every member need an account?

Not necessarily. Identify which tasks need authenticated access and which can be completed without an account before designing onboarding.