AscendixRE is a managed package that upgrades itself, so its objects, fields and logic are not yours to edit. A great deal can still be configured, and almost anything can be built alongside it — provided someone knows exactly where that line sits. Twopir Consulting works both sides of it, deliberately.
Trusted by 500+ organizations — with a 40+ consultant team building on the Salesforce platform AscendixRE runs on.
Extension Disciplines
Customization debt in a managed package compounds differently to debt in a normal org: the vendor keeps shipping releases into it. These are the six patterns that cost the most.
A Flow that also fires on Deal close, layered over the mapping the package already runs, produces duplicate comps and a race nobody can reproduce. The packaged behaviour has to be understood before anything is added to it.
The Enterprise tier caps custom objects at 15. Three projects each creating "just one more" leaves no headroom for the fourth, and the object you most need is the one you cannot have.
Ascendix's own guidance on Object Field Mapping is that manual testing is recommended because validation is not performed automatically. Teams read that as boilerplate. It is not — it is the warning label.
Ascendix publishes a user guide, not a schema reference. Apex written against object and field API names nobody verified, or against a relationship assumed to be master-detail, breaks on a release nobody can roll back.
A commission dialog cannot exceed 10 fields or contain parent relationship fields. A scorecard supports neither attachments nor multi-currency. Designing against these late means redesigning, not configuring.
Undocumented customization in a package that auto-upgrades is the worst combination in the stack. Six months later nobody can say whether a behaviour is the vendor's, yours, or an interaction between the two.
AscendixRE customization is the work of shaping Ascendix Technologies' managed CRE package to a specific business without modifying the package itself — through the configuration Ascendix exposes, and through Salesforce development built alongside it. The distinction is not pedantry. A managed package installs with automatic upgrades, so its components are sealed; work done inside them would be overwritten or would block the upgrade entirely.
The configuration surface is genuinely wide. Ascendix documents relabelling tabs and fields (Accounts to Companies, Type to Relationship), list view columns, record layouts, field visibility and positioning, colour schemes, related lists, Lightning record pages, org-wide sharing and permission sets, admin-controlled enable and disable of validation rules, the Object Field Mapping that drives deal close behaviour, field-value logic through Custom Metadata Records, and label language. Ascendix frames this as "what can't you customize?" — which is marketing. The real answer is the published limits, and we set them out in full below.
Beyond configuration. Salesforce's own toolkit remains available: custom objects and fields, Flow, validation rules, Apex, Lightning Web Components, reports and dashboards. All of it sits outside the package and references it. The package exposes at least one global Apex entry point for conditional field-value logic, which is the sanctioned way to extend that specific behaviour rather than route around it. What we never do is modify Ascendix components — and on an OEM-licensed org, we first confirm what the licence permits, because the custom object ceiling and third-party package access differ from a standard org.
Where this sits. If the package is not yet live, the build itself is covered by AscendixRE implementation. If the requirement is connecting AscendixRE to another system rather than extending it, see AscendixRE integration. For the platform context, see Salesforce for commercial real estate, and Ascendix's own help centre documents the package's configuration surface directly.
Every requirement gets solved at the shallowest depth that will actually hold. Reaching for code first is how an org becomes expensive; refusing to reach for it at all is how a workaround becomes permanent.
Everything the Salesforce setup menu and the AscendixRE Admin Console expose, with no metadata deployment and no code review.
Where it stops At anything needing conditional behaviour. A layout can hide a field; it cannot decide what that field should contain.
Declarative logic that changes behaviour and is still fully visible in metadata — versionable, reviewable and safe to hand over.
Where it stops At the package's published limits and at genuine algorithmic work — a commission model with real tiering is not a Flow.
Apex, Lightning components and custom objects, written against API names verified in your org and tested against the packaged behaviour.
Where it stops At the package boundary. We build beside Ascendix's components and never inside them, so a vendor release stays a routine event.
Before any code is written we run a describe against the org: object and field API names, the package namespace, relationship types and which components are global. Ascendix publishes none of this, and Apex written against a guessed API name is a defect waiting for a release to trigger it. The describe takes an afternoon; discovering the guess was wrong takes a sprint.
These are the requirements that come up on nearly every AscendixRE org once it has been live for a quarter and the business has stopped describing what it wants in the abstract.
Making the package speak your firm's language, so brokers stop translating between the screen and the deal.
Extending what happens when a Deal closes, carefully, because this is the automation everything else depends on.
Where the packaged commission engine stops and your partnership agreement keeps going.
The questions leadership asks that the packaged objects cannot answer on their own.
Custom code where the requirement is genuinely algorithmic — written to survive the next vendor release.
Extending broker confidentiality to the custom data your customization creates, rather than leaving a gap.
Ascendix publishes these on its own limitations page. We treat them as design inputs from day one, because each one turns a configuration conversation into a development conversation the moment a requirement crosses it.
| Area | Published limit | What we do about it |
|---|---|---|
| Custom objects | Capped at 15 on the Enterprise tier. | Treat the ceiling as a budget held across the roadmap, not per project. Model on packaged objects and custom fields wherever an object is not genuinely required. |
| Commission field sets | Maximum 10 fields. Multi-select picklists, rich-text areas and parent relationship fields cannot be added. | Keep the dialog to the fields a broker edits. Anything derived moves to a custom screen or a formula surfaced on the layout instead. |
| Custom editable grid | Displays a maximum of 1,000 records and updates a maximum of 500 at once. | Filter grids by default rather than paginating a full set, and move genuine bulk operations to a purpose-built batch process. |
| Property import | Processes in 99-record chunks; a single record error blocks that chunk's address updates. | Pre-validate addresses, load in deliberately small batches, and plan iterative cleanup cycles instead of one migration window. |
| Scorecards | No Notes and Attachments relationships, and no multi-currency support. | Where either is a hard requirement, the scorecard becomes a custom component rather than a configuration of the packaged one. |
| Web-to-Inquiry | Accepts yyyy-MM-dd only — no time or DateTime fields. | Capture the date on the form and derive any time component after submission, rather than asking the form to carry it. |
| Image viewer | 25 MB file upload cap, with one related-record identifier unavailable for the listing portal. | Compress on upload and keep large marketing assets in a document system referenced from the record. |
| Editions | Essentials and Group are unsupported; Professional Edition cannot run SOAP Apex web services. | Confirm the edition before any integration design, since the available extension mechanisms differ materially between them. |
A partner who only describes what a package can do is not much use when you are three months in and have hit something it cannot. These limits are public, they are stable, and knowing them in advance is the difference between a quoted change and an awkward conversation. If a requirement on your list crosses one of these rows, that is worth knowing before you brief anyone — us included.
Every customization goes through the same five steps whether it is a relabelled picklist or an Apex service. The small ones just move through faster.
What the business actually needs, and the shallowest depth that will hold it — configure, declare, or build. Most requests resolve one rung lower than they arrive.
Which packaged objects, fields and automation the change touches, read from the org rather than assumed, plus what else depends on them today.
Implemented outside the package, against verified API names, with the existing packaged behaviour left intact and observable.
Deal close, comp creation and commission calculation re-tested against real transaction types — because the vendor's own guidance is that mapping changes are not validated automatically.
Deployed through a real release process and written down — what changed, why, and what a future Ascendix release should be re-tested against.
The engagements below ran on Salesforce and Propertybase rather than AscendixRE, and are labelled accordingly. What transfers is the discipline: customisation that extends a real estate platform without compromising the compliance and commission logic sitting under it.
Twopir Consulting transformed our real estate operations by unifying AML/KYC, inquiries, contracts, and commission tracking into a single Salesforce–Propertybase platform. Their API-driven approach automated workflows, reduced errors, and enabled real-time data synchronization. With improved visibility, collaboration, and compliance, we now operate faster, smarter, and with greater confidence.
Custom CRM automation that cut manual property management workload.
The question we ask about every customization is not "can we build this" — almost always we can. It is what this will cost to own in two years, after eight vendor releases have shipped into the org underneath it. That question tends to move a requirement one rung down the ladder, and the business rarely misses the difference.
Apex, Lightning and integration work across Salesforce and HubSpot ecosystems.
We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we serve enterprise organizations on the same terms. Extending a vendor package safely is one of the clearest tests of that discipline.
A relabelled picklist that solves the problem beats an Apex trigger that solves it more elegantly. Code is the last option, not the first, and we will tell you when a request does not need us.
Everything sits beside it and references it. That is what turns an Ascendix release from a regression hunt into a routine event, and it is not negotiable regardless of how convenient the alternative looks.
Ascendix publishes labels, not identifiers. Every object and field we reference comes from a describe against your org, so nothing in the codebase rests on a plausible-looking guess.
Deal close writes comps and closes availabilities. Any change near it gets tested against real transaction types before release, because the package does not validate mapping changes for you.
Every change is recorded with what it touches and what to re-test on the next release. You should be able to change partners without losing the ability to maintain your own org.
More than most managed packages, but the framing matters. Ascendix documents configuring tab and field labels, list view columns, record layouts, field visibility and positioning, colour schemes, related lists, Lightning record pages, org-wide sharing and permission sets, the Object Field Mapping behind deal close, field-value logic through Custom Metadata Records, and label language. On top of that sits everything Salesforce itself offers — custom objects and fields, Flow, Apex, Lightning Web Components, reports and dashboards. What cannot be changed is the package's own components, because it installs with automatic upgrades. The practical ceiling is set by the published limits rather than by imagination.
Not if it was built correctly, and reliably if it was not. AscendixRE installs as a managed package with automatic upgrades, so anything built inside the package's own components is either overwritten or blocks the upgrade. Work that sits alongside the package and references it survives, which is why we treat the boundary as absolute. The residual risk is behavioural rather than structural: a release can change what the packaged automation does, so anything depending on deal close or commission calculation gets re-tested after a release rather than assumed. That re-test is part of what an ongoing support arrangement covers.
You can, within a ceiling that depends on your licence topology. The AscendixRE Enterprise tier caps custom objects at 15, which is an entitlement ceiling rather than a technical one — and it applies across everything you will ever build, not per project. If AscendixRE runs inside a Salesforce org you already own, your own edition's limits apply instead and are usually far higher. Either way we treat the count as a budget: before adding an object we check whether custom fields on an existing packaged object, or a different relationship, would carry the requirement without spending one.
This is the single most common reason a brokerage needs development rather than configuration. The packaged engine covers tiered house splits, YTD thresholds, multi-broker deals, split validation against 100% and invoicing, with role-based privacy — and the calculation can be disabled entirely where a firm needs its own. The constraint that bites first is the commission dialog's 10-field ceiling, which excludes multi-select picklists, rich-text areas and parent relationship fields. We usually keep the packaged engine for the standard cases, keep the dialog to the fields a broker genuinely edits, and build the firm-specific tiering as an Apex service beside the package, with its results surfaced on the layout.
Yes, and this is the change we treat most carefully on any AscendixRE org. Closing a Deal drives downstream record creation — a leasing deal produces a lease comp, an investment sale produces a sale comp, and the related Availability can be closed out — with the behaviour driven by Deal Sub Type and configured through Object Field Mapping in the Admin Console, which supports both dynamic and static mappings. Ascendix's own guidance is that manual testing of all changes is recommended because validation is not performed automatically. We take that at face value: every mapping change is regression-tested against each real transaction type before it goes near production, because a silent failure here stops comp history being created and nobody notices for a quarter.
Yes. We start with a full describe and metadata audit that separates three things people usually have merged in their heads: what the managed package does, what previous customization added, and what is an interaction between them. That distinction is almost always the hard part — a behaviour blamed on the vendor turns out to be a Flow someone added in 2023, or vice versa. The output is a documented map of every customization, its dependencies, and a prioritised list of what is safe to keep, what should move to a shallower depth, and what is a genuine risk on the next release.
Often, and it is usually the best-value arrangement. A capable in-house admin handles the configuration depth — labels, layouts, list views, permission sets, reports — while we take the declarative logic and development work, and the regression testing around packaged automation. What matters is agreeing the split explicitly and keeping one change log, because the failure mode is two people changing adjacent things in the same week with no record of either. Where a team wants that coordination handled for them, our AscendixRE support and managed services covers it.
We will tell you which depth it belongs at, what it touches, and what it will cost to own after the next few vendor releases — before anyone writes a line of code.
Related: AscendixRE consulting, implementation, integration and support — or the wider Salesforce for commercial real estate practice.
