Request and approval systems
A purchase request is raised, checked against budget and passed to the authorised manager; the outcome is followed from the same screen.
WEB-BASED ENTERPRISE APPLICATIONS
Enterprise Web Application Development
We move the workflows currently running on spreadsheets and email into web applications where people sign in, roles and permissions are defined and every step is recorded. Nothing is installed: updates happen in one place and everyone works on the same version.
What is a web application?
A web application is software that runs through the browser and lets people create data and carry out transactions. The user signs in with their own account, sees screens according to their role and creates records that then go to someone else for approval or across to another system.
What separates it from a desktop program is that nothing is installed on the user's machine. The application runs on a server, and access from outside the office is possible within whatever permission rules you set.
The difference between a website and a web application
A website focuses on presenting the company, its services or its products, and on publishing information. The visitor is mostly a reader.
In a web application the user signs in, creates data, carries out transactions, approves work or runs the daily operation. Its value lies not in how the page looks but in the process it runs.
If you are looking for a corporate site, our corporate website design and development page is the better fit; this page covers applications that run a process.
Which business processes can move to a web application?
Any process where several people work in turn, approval is required and it has to be clear afterwards who did what is a candidate. The headings below are the ones most often moved.
Typical use cases
Internal portals and self-service
Announcements, documents, forms and self-service tasks such as leave and expenses, all handled in one place.
Dealer, B2B and customer portals
Dealers order from their own price list and see their balance and shipment status; customers track documents and raise requests.
Operations and work order screens
Who the job is assigned to, what stage it is at and when it closed, followed from departmental screens.
Data capture applications
Audit, inspection and count forms validated and collected in one place.
Management and reporting dashboards
Data from different systems brought into one role-filtered screen.
Applications that complement the ERP
Side processes that do not belong in the ERP but depend on ERP data.
Users, roles and permissions
Role design is not only security; it is where the application's business rules are set: who sees which screen and above what amount approval is required.
- Users signing in with their own accounts
- Role-based screen and document permissions
- Approval levels that change with amount or category thresholds
- Users seeing only their own region, warehouse or customers
- A separate permission scope for external users (dealers, customers, suppliers)
- Permission changes recorded
Single sign-on and corporate authentication
In companies running a corporate identity platform, sign-in can be wired to employees' existing accounts. That avoids another set of passwords to manage, and access for someone who leaves is cut centrally.
It is not mandatory; it is assessed against user numbers and the infrastructure you already have. For portals opened to outside users, a separate user management arrangement is designed.
API, ERP and third-party integration
Most enterprise web applications do not work in isolation. They read item, price, stock and account data from the ERP and write the resulting order back as a document. Without that flow the same data is kept in two places and drifts apart.
On the SAP Business One side we make the connection through the service interfaces shipped with the product. For other systems we use the API the other side offers, and on failure a record does not disappear quietly: it collects in a visible queue.
Mobile support
Designed to be mobile-friendly, the application can be used from a phone or tablet; for approving, checking status and viewing lists that is usually enough.
- A single-column layout on narrow screens with large enough touch targets
- Forms that can be completed from a phone
- Lists and tables that do not overflow sideways
- A route to a mobile app where camera, barcode or offline working is needed
Security and audit trail
Security is not added afterwards: authentication, permission separation, input validation and audit logging are part of the design from the start.
- Authentication and session management
- Input validation and controls against unauthorised access
- Visibility of who created a record, and when
- Traceability of the stages a document passed through
- Data isolation in portals opened to outside users
- Defined backup and hosting arrangements
The project process
01
Process analysis
We map how the flow runs today, who does which step and what the exceptions are.
02
Screen and permission design
We put the roles, screens and approval levels in writing.
03
Development and integration
We build the application and connect it to the ERP and other systems.
04
Testing and user acceptance
Users run their own work through the system and integrations are tried with real data.
05
Go-live and support
Training, first use and regular support afterwards.
What drives the cost
What sets the budget is less the screen count than the number of roles, the exception rules, the number of integrations, whether outside users are involved and how much existing data has to be migrated.
Our custom software development cost guide covers those items in detail, along with what to settle before asking for a quotation.
Frequently asked questions
Does a web application need to be installed on users' machines?
No. It runs on a server and users reach it through the browser. Updates happen in one place and everyone works on the same version.
Can it be built inside our existing website?
Setting it up as a separate application is usually the better route: a public site and a business application behind a login have different security, backup and update requirements. The two can still link to each other.
Does it replace our ERP?
No, it generally complements it. Side processes that do not belong in the ERP but depend on ERP data run in the application, and the outcome is written back to the ERP as a document.
Can our dealers and customers use it too?
Yes. In portals opened to the outside, authentication, data isolation and security requirements differ from an internal application and are treated as a separate item in the scope.
Related pages and guides
LET'S TALK
Tell us what you need and we will work it out together.
In a short call, we'll listen to your process and decide the right path together: off-the-shelf or custom development.