Evaluate
Don't take our word for it. Test it on your own site.
Visual styling tools fail in three predictable places: selectors that break on the next release, merges that silently clobber existing CSS, and handoffs that arrive as loose snippets. OmniStyler was built around those failure points, and Experience Cloud is where they bite hardest, so that is exactly where you should test it. Twenty minutes on your own portal, or any site you own, beats any testimonial.
What you can inspect before installing
Selector examples
The engine prefers stable anchors like data-test-id, falls back to wrappers such as .siteforceContentArea, and rejects generated Salesforce class tokens.
Merge examples
The merge engine uses a real CSS parser, updates matching top-level rules, preserves unrelated CSS, and reports higher-specificity or existing !important conflicts.
Deploy output
The deploy kit contains static-resource CSS, metadata, Head Markup, component design tokens, and a README with the exact Salesforce CLI commands.
Local demo
The packaged extension can be tested on demo/index.html, a mock portal with FlexCard-style anchors and SLDS-like structure, before touching a real org.
The twenty-minute evaluation
Run this on an Experience Cloud portal, the hardest case OmniStyler is built for. Clear it there and you have your answer for every easier site: the same loop, selectors, merge, and handoff work the same way on a landing page or a marketing site.
1. Selector stability
Pick a FlexCard or SLDS component, restyle it, then reload the portal and navigate away and back. The rule should still target the same surface, because it anchors on data-test-id, not on the class names Salesforce regenerates.
2. Merge behavior
Paste your portal's existing Head Markup CSS, merge your edits into it, and diff the result. Unrelated existing rules should survive untouched, and the conflict report should flag anything that still outranks your changes.
3. Review workflow
Duplicate a theme, mark it in review, add a note, and export the standalone preview. A stakeholder should be able to approve the design without Salesforce access or a screen-share.
4. Deployment handoff
Download the deploy kit and hand it to a developer cold. The static resource, metadata, head markup, and README commands should be enough to ship without a single follow-up question.
What a pass looks like
- Rules keep applying after reloads and normal Salesforce DOM churn.
- The merged stylesheet preserves every unrelated existing rule.
- A designer produces a client-ready preview without admin access.
- A developer deploys from the kit without asking what goes where.
- Draft, review, approved, and archived variants coexist on one site or portal without stepping on each other.
Ran the evaluation on a real project? Tell us how it went, especially where it fell short. Before/after stories we publish with explicit approval; rough edges we fix. Either way: [email protected].