# Building Performant Solutions in Nextworld

**URL:** <https://community.nextw.com/t/building-performant-solutions-in-nextworld/1848>\
**Category:** How Tos\
**Created:** [March 19, 2026, 4:37pm UTC](https://community.nextw.com/t/building-performant-solutions-in-nextworld/1848 "2026-03-19T16:37:34Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![bethany.k](https://sea1.discourse-cdn.com/flex001/user_avatar/community.nextw.com/bethany.k/32/111_2.png) [@bethany.k](https://community.nextw.com/u/bethany.k)\
**Post date:** [March 19, 2026, 4:37pm UTC](https://community.nextw.com/t/building-performant-solutions-in-nextworld/1848/1 "2026-03-19T16:37:34Z")

</div>

Building performant solutions on Nextworld isn’t just about speed; it directly impacts your customers’ experience, your solution’s scalability, and your reputation as a partner. Use this post as a reference during design and before go-live.

#### Tip #1: Clean Code in Logic Blocks

- Keep each logic block focused on a single purpose.
- Reuse logic instead of recreating it — avoid doing the same thing in multiple logic blocks.
- Use inputs & outputs to reduce extra data fetching.
- Every action should serve a real purpose and be executed in the right order. Unneeded actions slow things down, especially in reports.

> 💡 See the _Logic Block Performance Best Practices_ article in NW Help for more.

#### Tip #2: Fetch Smarter, Not Harder

- Use filtering criteria to get only the data you need — avoid long-running fetches.
- Use `Limit=n` when applicable. Fetching only what’s needed is much faster than fetching everything. See [Limits on fetches vs performance](https://community.nextw.com/t/limit-on-fetches-vs-performance/1013) Community post for additional information on this topic.
- Apply filters on the fetch, not inside the loop. Use _Exit Loop_ when the data you need is found.
- Only sort when your logic requires it (e.g., group-breaking logic).
- Align index order with your logic flow for large datasets.

> 💡 See the _Fetch Performance Best Practices_ article in NW Help for more.

#### Tip #3: Avoid Logic Blocks Over Header/Detail Tables

Unless your logic block is called directly by the UI, build over Header and/or Detail tables:

- Add header/detail tables as inputs/outputs
- Fetch detail records in a child logic block

#### Tip #4: NATE Considerations

- Design logic blocks to run with and without NATE.
- Use NATE for background processing **only when necessary** (e.g., background logic blocks and workflow definitions).
- Consider _Fetch Records_ instead of _Fetch Detail Records_ for detail tables — Fetch Detail Records incurs extra updates to the header record. If using Fetch Records on a detail table, include the `nwHeaderId` filter expression and add an explicit Update Record.

### Design-Time Performance Checklist

**Table Fetches**

- Will data accumulate over time? If so, what’s your plan for purging it?
- How fast does the feature need to work?
- What guardrails are needed? _(e.g., preventing the generation of a 3.7 million-page report PDF)_
- Are you fetching the minimum number of rows necessary?
- Are you looping over the same data more than once?
- Can you use `Limit 1` on your fetches? Is a sort absolutely necessary?
- Are you validating in the appropriate place — and no more than necessary?

**Workflow**

- Could any Automatic transitions be moved to Logic Block-controlled transitions?
- Do you have long-running logic in a workflow transition that should move to a background task?

**Job Queue / Processing**

- How many transactions will this push to the job queue in a short amount of time?
- Should you enable Asynchronous Processing for large transactions?
- Are all inline validations necessary?

### Performance Testing

1. **Identify key areas** — Where do speed and efficiency really matter in your solution?
2. **Set goals** — Define response time targets and throughput expectations.
3. **Establish baselines** — Test with realistic data volumes using integrations (e.g., Excel uploads) or API imports (Postman / Python scripts). Use Application Monitoring to execute tests and analyze counts and times.
4. **Optimize** — Apply the tips above and reference additional resources in NW Help.

#### Testing Prep Questions

- How many records need to be processed per second/minute?
- How many records will be in the tables the feature queries?
- Which parts of your design should be tested with Application Monitoring?
- What should your test data look like?
- Which tables will be fetched, updated, or inserted — and how many of each?