Portals
Internal, customer, partner, training and multi-language portals, built around a clear rule for which user sees which records.
The first design question for any portal is who sees what. A dealer portal, a client document portal and an employee training portal all look different on screen, but each one has to decide which records belong to which user or group, and enforce that on every request.
IKRC builds portals as standalone applications or as part of an intranet or extranet, with branding, content and rules that vary by group. The data boundary is designed and tested first. In an EF Core application that keeps several customers in one database, a global query filter on a tenant ID column adds that condition to EF Core queries against that entity type. A developer can still switch it off for a single query with IgnoreQueryFilters(), so each use of that call needs review and a test. The filter does not cover SQL run outside EF Core, such as stored procedures, reports or other services reading the same database, and it does not check the tenant on records being saved; those paths need their own tenant checks.
Multi-language content, video libraries and training tracks sit on top of that boundary. For more on tenant isolation and support access, read Multi-Tenant Software Is a Boundary Problem, Not a Database Column.
Ready to get started?
Describe the system or process you want built or fixed, and we will follow up to talk through the project.
Contact IKRC