Skip to main content
Version: 8.2All Creatio products

App development basics

Apps are function blocks that solve business problems and are the main unit of Creatio no-code development. No-code tools streamline the app creation process and make it accessible for both professional developers and business users.

The app creation process involves multiple phases regardless of the app scale and purpose:

  1. Design. Read more >>>
  2. Go-live. Read more >>>
  3. Everyday delivery. Read more >>>

The article covers each phase with emphasis on the best practices. You can use Service Creatio to track app development, improvement, and support efforts. This product lets you manage changes, problems, and releases. Learn more: Case Management.

Design​

Business use case. Start working on the app by specifying business requirements, i. e., project goals and objectives, at a high level. This involves the following steps:

  • Define the app stakeholder.
  • Determine business processes the app is going to implement, then decompose them into smaller process use cases.
  • Review how consistent the use cases are across your organizational structure.
  • Define the success criteria.

Options analysis. Once you have a business use case, determine whether no-code is the best possible approach. Coding or ready-made apps on Creatio Marketplace help to resolve some business problems more effectively. To determine the best avenue of approach, we recommend answering the following questions:

  • How standardized is your business process? Highly standardized business processes, for example, accounting, might already have an app on Creatio Marketplace.
  • How much customization is needed to meet your business needs and provide a competitive advantage? Little customization means a Creatio Marketplace app might be a better solution. A lot of customization means coding might work better.
  • How technically complex is your case? You can add custom-coded functionality to a no-code app, but particularly complex cases might not need no-code functionality at all.
  • Are there any custom integrations required? In some cases, you might want to develop a custom app to ensure the integrations work as intended.

Design and prototyping. While traditional development requires design documents and external tools, for example, Figma or Adobe XD, Creatio No-code Designer lets you create prototypes that already contain basic functionality. That said, do not attempt to create a ready-to-release minimum viable product (MVP) at this stage. Settle for something that is close enough to your vision:

  • Create a single happy path for a user in the UI.
  • Focus on the top-level workflow, for example, the main business process.
  • Simplify the integrations. You can use REST/SOAP services, prebuilt connectors, or simple mockups if custom integrations are required.
  • Add only simple dashboards that display KPIs.

Project assignment. The final stage of the design phase requires you to narrow the scope to plan for an MVP. We recommend taking the following steps:

  • Decompose the business use case. This will help you see which subprocesses to include in the MVP.
  • Prioritize and confirm the go-live scope of subprocesses with the stakeholder. We recommend stack-ranking subprocesses for prioritization. To create and prioritize tasks, use tools that support online access, co-editing, change versioning. For example, you can use Visio to describe the requirements as processes. Cloud test editors, Confluence, Jira, Miro are optimal for managing text descriptions. Use online tables or User story mapping format in Miro, Jira for prioritization.
  • Apply timeline constraints. Understand the business timetable and check whether you have a defined timeline linked to the success criteria.
  • Set up future project enablement. Make sure you have the additional resources required for the project to succeed. This can include the following:
    • power user recruitment
    • governance checks
    • user enablement plans
    • no-code environments
    • release strategy

Go-live​

Prototype-to-MVP. We recommend starting app development from an existing prototype you created during the design phase. This lets you accelerate development. Take the following steps as part of the app development:

  • While you concentrated on a single happy path when creating a prototype, now is the time to branch out by adding other paths. Ensure the data source structure is clear and consistent. Set up business rules if needed. This is also a good time to review brand and UX to ensure the app is in line with corporate branding.
  • Add more details around subprocesses and individual tasks, improve edge cases, and ensure processes handle errors gracefully.
  • If your prototype has integration mockups, it is time to implement them fully.
  • Ensure the dashboards cover key aspects required for analysis. Add more widgets if needed.
  • Test end-to-end scenarios and APIs. Test the app on the user group that corresponds to the real target audience. In this case, the test scenario must direct users without imposing correct solutions on them.

If you want multiple developers to work on the app, make sure that the following requirements are met:

  • Developers have access to the version control system that stores the composable app at the development stage and the change history of the app.
  • Developers understand the commands from the version control system client.

A single version control system can include multiple repositories. However, one repository can store only different versions of a single composable app. You can track changes since the commits of different apps do not cause a conflict.

When you work on a single data source, ensure developers discuss changes in advance and make agreements. This prevents conflicts when committing changes. If a change commit causes an error, resolve conflicts using default tools of the version control system client.

Important

Working together with properties of the same element might cause a conflict that must be solved manually.

The exception is conflicts that occur when you work collaboratively on configuration elements stored in the package properties. For example, ClientSchema, EntitySchema, ProcessSchema. You cannot resolve these conflicts using default tools of the version control system client.

Feedback loop. While it is a good idea to collect feedback at any stage, processing it intelligently requires a dedicated framework. We recommend taking the following steps:

  • Communicate with a stakeholder. It is most efficient to work with a single stakeholder who has a good understanding of the business process, has sufficient authority to make functionality-related decisions, and understands the technology.
  • Build and review micro use cases. Develop the app in small chunks and review each chunk as soon as it is ready. This lets you do feedback sessions quickly, efficiently, and regularly. We recommend aiming for multiple sessions per week.
  • Triage Go-Live scope. Even though you are collecting feedback constantly, keep the MVP in focus. Check which feedback you can implement in the MVP and which feedback goes to the backlog.
  • Keep addressing feedback after release using the same procedure.

Governance checks. Although No-Code Designer helps to accelerate development and empower employees that have no coding skills, if you expect your app to be used by real users, it still must comply with a variety of rules and regulations. As such, check whether your app complies with the following checklists:

  • External compliance. For example, external laws, guidelines, and regulations imposed by governments, industries, or organizations.
  • Internal compliance. For example, rules, regulations, and practices as defined by internal policies and access controls.
  • Security. For example, rules to protect your corporate information resources from external or internal attacks.
  • Data governance. For example, assessments of how sensitive corporate data is managed and secured.

First release. Before you can release your app to the users, make sure your infrastructure can support it. This includes both users and technology.

As far as users are concerned, unless your app is very small, you are going to need app documentation and a dedicated support team. You can create documentation in the Knowledge Management app and establish the support workflow in the Case Management app.

Also, consider how you are going to onboard users to your new app. It might be better to use phased onboarding to ease both the users and your infrastructure into the app gradually.

As far as technology is concerned, the release pipeline has to include multiple environments. The exact number of needed environments can vary depending on the app complexity. For example, a small app might only require a development and production environment. However, larger apps might require the full set of environments, specifically:

  • Sandbox. Use it to prototype the app and test the prototype as much as needed without the changes affecting the actual development.
  • Development. Use it to create apps.
  • QA. This environment must be new to ensure existing business logic and data do not impact the delivery and test results. Use it to test the app. To ensure the high quality of the app, automate the testing steps using a CI/CD server. This lets you receive test results immediately, which speeds up the preparation of release artifacts.
  • Preproduction. This environment must mimic the production environment, i.e., live site. Use it to perform final tests to ensure the customizations do not impact the existing business logic and work as expected.
  • Production. This is your live site that actual users use. Install the app into a production environment only after the app has been tested successfully and recognized as a release version.

Once you have the infrastructure prepared, obtain approval for release from the stakeholder and perform the final user acceptance test. Since released app is the priority at this stage, validate only the highest-level business requirements. Accept only the most critical feedback and move everything else to backlog.

Everyday delivery​

Feedback collection. Development is not over once you release an app. It is important to keep improving it. To do that, collect feedback from the stakeholder, end users, and system itself. You can collect feedback using a wide variety of methods, for example:

  • email surveys
  • focus groups
  • user shadowing
  • UX questionnaires
  • in-app feedback widget
  • net promoter score
  • usage analytics

Avoid common pitfalls while you collect feedback:

  • Prioritizing vocal minority of users. To ensure you are dealing with a truly significant issue, cross-reference user feedback with app data you collect.
  • Prioritizing infrequent users. It is important to collect feedback from any type of users, but infrequent users are not going to provide as much insight as power users.
  • Processing feedback slowly. Keep up the pace similar to what you did during the go-live phase. Schedule feedback sessions multiple times a week.

Incremental improvements. It is important to keep improving the app. Unlike traditional development, No-Code Designer can deploy improvements in smaller increments. This lets you adapt to changes and process feedback much more quickly. We recommend taking the following steps as part of this stage:

  • Create new app uses cases based on feedback data and decompose them to micro use cases.
  • Prioritize feedback based on how it can let you achieve business goals. Approve the use case priority with a stakeholder.
  • Build and test enhancements once you have a priority list. We recommend creating a unified backlog of features. It is also important to ensure new changes don’t break existing features.
  • Sometimes you might need to change the entire app design as part of improvements. This is fine. You might even return to options analysis to see what type of development works best for the app in its current state.
  • You might need to pass more governance checks as changes might influence the complexity level of the application. For example, additional access permissions. Everyday delivery. Deliver the improvements you created as quickly as possible. In general, the procedure to deliver changes during this stage is the same as during Go-live phase. However, we recommend you shift your focus to implementing micro use cases. Users generally adapt to smaller changes easier. Also, inform users about your updates, be it through release notes or training sessions.

Application audit. Keep auditing the app to ensure it remains compliant with standards and remains useable. Review the following:

  • App itself. Review the UX complexity, app performance, and the impact of data on performance.
  • Feature and app obsolescence. Retire features once users no longer need them. Also, retire the app itself once it reaches its end of life.
  • Organization changes. Make sure the app is always in line with current operational process and organizational structure.
  • Governance changes. Make sure the app is always in line with current internal and external requirements.
  • Component reuse. Some of the components you created during development might be useful for other projects. This is going to accelerate further app development significantly, so be on the lookout for them.

See also​

Manage apps