No two organizations run HR in exactly the same way. Approval structures, internal processes, access requirements, forms and administrative conventions all vary. The challenge for an enterprise HR platform is to accommodate those differences without turning every requirement into a separate custom development project.
Customization has therefore always been an important part of SunFish. During implementation, the system is configured around the way an organization operates. SunFish also includes tools that customers can use directly for suitable changes, including login-page settings, template colours and fonts, homepage widgets, favourite menus and Report Builder.
SunFish’s new Page Builder belongs to this broader customization direction, but it serves a different primary purpose. It is an implementation tool for creating company-specific HR application pages through configuration rather than changing the standard SunFish front-end code for each new requirement. Implementation teams can define the page structure, routing, rendered components, access and basic behaviour in a more organized environment.
This can reduce the amount of custom code that must be developed, tested and maintained during an implementation. Because the finished page is configuration-based, it may also be easier to adjust after go-live.
What SunFish’s Page Builder changes in an implementation
A company-specific HR page has traditionally required more than deciding what it should look like. Developers may need to change front-end code, connect the page to the application structure, apply access rules and test the complete result. Even a relatively contained requirement can therefore pass through design, development and verification before it is ready for use.
SunFish’s Page Builder moves suitable requirements into a structured configuration process. An implementer can define a page, place it in the correct SunFish menu, establish how the application reaches it and assemble the page from available elements. The standard SunFish front end does not need to be changed for every new page.
This does not mean that every requirement becomes a Page Builder task. New business logic, complex transactions, integrations or functions outside the supported components may still require product development. The new Page Builder creates a clearer path for requirements concerning page structure, navigation, access and supported behaviour.
The configuration area has two main parts. The Page List shows the pages that have been created and the menu group connected to each one. The Component Library contains reusable templates that can be applied to future pages. Together, they help implementation teams manage individual pages while building a consistent set of reusable structures.
From a requirement to a working page
Creating a useful application page involves more than arranging fields on a screen. The page needs a logical place in the application, a route that SunFish can recognize and an access setting that determines who may reach it. The Page Builder brings these decisions into one implementation process.
The implementer first creates the page record and decides where it belongs. The relevant menu group and menu option are selected, the page is given a title and its display order is defined. If the access configuration needed for the page does not yet exist, the Page Builder can create it as part of the setup. This keeps the page, its navigation and its permissions connected.
The next step is routing. A route defines how SunFish reaches the page. It includes a route name, page link, access code and access mode. Separate routes can be configured for different permitted uses, depending on what the page is intended to support. The implementation team has one place to confirm that the correct path and access settings have been assigned.
Once the menu and route are in place, the implementer assembles the page itself. The configuration workspace contains a library of elements, a central canvas and a settings panel. Elements are placed on the canvas and configured for the requirement. The selected element is highlighted so it is clear which part of the page is being edited.
The available building blocks include basic elements supplied by SunFish and custom elements created for a particular need. Depending on the element, the implementer can adjust its layout, style and basic behaviour. Elements can be moved, removed or saved as reusable components. This gives implementation teams room to accommodate the requirement while keeping the resulting page within a structured SunFish environment.
Using SunFish Intelligence to accelerate page setup
SunFish Intelligence’s AI assistant can help implementation teams create the first version of a page from a natural-language description of its purpose, structure and required fields. It translates the requirement into an initial page configuration using supported elements, field types and basic settings.
The resulting page remains fully editable in Page Builder. The implementer reviews the structure, adjusts the configuration and confirms the routing, access and behaviour before testing and releasing it.
This AI-assisted option can reduce repetitive setup work, while manual page creation remains available when the team prefers to configure each element directly.
Building once and reusing the result
The Component Library matters because implementation requirements are rarely completely unique. Similar arrangements can appear across employee services, administrative pages and internal forms. Rebuilding the same structure repeatedly takes time and can introduce small differences that make later support more difficult.
When an implementation team creates an element or arrangement that will be useful again, it can be saved as a component. That component becomes available for other Page Builder pages. The team can begin with a proven structure and adapt it to the next requirement instead of rebuilding every part from the beginning.
Reuse can shorten delivery while supporting a more consistent employee experience. Pages created at different stages of an implementation can follow the same layout conventions and use familiar components. Approved patterns can be carried across requirements without forcing every page to look or behave differently.
When SunFish’s Page Builder is the right tool
Consider an organization that wants a dedicated internal career page in SunFish. The employee information, vacancy data and access rules already exist, but the company wants to present them in a structure that better reflects its internal career process.
The first question for the implementation team is whether the requirement can be met using existing SunFish services, access controls and supported components. If it can, the page is a suitable Page Builder requirement. The implementer can configure the page and connect it to the existing application structure without developing a separate front end.
The page still needs to be reviewed and tested. The difference is that the team is verifying the configuration, routing, access and rendered result rather than developing and maintaining another piece of custom front-end code. If part of the layout can be used elsewhere, it can also be saved as a reusable component.
The Page Builder would not be sufficient if the organization also needed new career-matching logic, a new approval process or another function that SunFish does not already support. Those requirements may still need product development. The value of the Page Builder is that a presentation and navigation requirement does not have to follow the same development path as a genuinely new system function.
For the company, this can shorten the implementation work and make later page adjustments more manageable. For employees, the result is simply a career page that appears in the right place and feels like a natural part of SunFish.
What changes after go-live
New requirements do not stop when the original implementation is completed. Organizations change reporting lines, introduce employee programmes, reorganize services and discover better ways to present information. Some changes justify a full development request. Others are primarily questions of page structure, navigation, access or presentation.
For suitable requirements, a Page Builder page can be adjusted through configuration rather than redesigned as custom front-end code. The implementation or support team can work from the existing page and its reusable components, which may make the change more contained and easier to verify.
A customer with appropriately trained technical staff and suitable governance may also be able to maintain selected configurations. Organizations can decide which responsibilities remain with DataOn’s implementation team and which they are equipped to handle themselves.
The feature also helps keep development work focused where engineering is genuinely required. New business logic, complex transactions, integrations and functions outside the supported building blocks may still need formal design and development. SunFish’s Page Builder provides a clearer way to separate configuration-level changes from deeper product work.
What employees experience
Most employees will never open the Page Builder, but they are the people who ultimately experience its results. A well-designed page can place information where employees expect to find it, reduce unnecessary navigation and make company-specific services feel like a natural part of SunFish.
Consistency matters here. Employees should not have to relearn the application each time a new page is introduced. Reusable components and common page structures help implementation teams work with familiar patterns. The organization receives a page suited to its requirement, while employees continue working within a recognizable SunFish experience.
The benefit is therefore not limited to the project team. A more efficient implementation method can make it easier to deliver the company-specific pages that help employees find and use relevant HR services. The technical change happens behind the scenes, but the outcome appears in the everyday application experience.
Closing the gap between standardization and customization
Enterprise HR platforms need both consistency and room for company-specific requirements. Too little flexibility forces organizations to work around the software. Too much custom code can make implementation, testing and later maintenance unnecessarily long and difficult.
SunFish’s new Page Builder provides another way to manage that balance. Implementation teams can define where a page belongs, how users reach it, what access it requires and which components it contains without changing the standard SunFish front-end code for every suitable requirement. Reusable components can then carry successful structures into future pages.
The result is a more efficient implementation approach. Company-specific pages can be delivered within the structure, navigation and access model of SunFish, while deeper development remains available when needed. Appropriately equipped customers may also find selected later changes easier to manage.
To discuss whether a company-specific page requirement can be handled through Page Builder, contact your SunFish implementation or account team.
