Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
A promising title again! 😆 For this post an interesting though that makes things sooooo much easier. It’s all about your mobile users (managers?) that need quick access to a task approval screen to hit “OK” or “REJECT”. A simple use-case…right? Well………
Let get right into it…
…You don’t want to know what kind of fancy implementations I see passing by in projects. When we think in mobile, it looks like suddenly everything is possible whatever it takes. Some scenarios:
- The native app; Fully customized (sometimes for multiple platforms), stored in the appstores, communicating with the typed ReST API layer of the platform (read here about the communication part)
- The hybrid app; Fully custom, one platform (because “hybrid”), stored in appstores, and communication over the same ReST layer.
- The webapp; Again, fully custom, one platform, served over a dedicated application server, communicating over ReST.
- The OT mobile App; Configurable over the ‘Mobile’ building of an entity and communicating via the separate “Mobile Gateway”…Have fun on the configuration part! 😅
- The Webcontent panel; Configurable as panel in your entity layout exposing solution data over the HTML5SDK or the new JS API (which is customization again!)
The last one is close already, but can we do better, can we be smarter, can we make it less complex? That’s the question!?
The most simple and elegant solution of all
This is the time to boot up your VM and tune in to your favorite URL of the AppWorks platform. Open the ‘Workspace Documents’ artifact and open a workspace (or create a new one) with a corresponding project. Let’s create ourselves a new ‘Case’ entity with just two simple properties; case_name (Text) and case_is_approved (Boolean; by default, NONE). Generate all the rest, make it naming-wise to your standards, and do a first publication into runtime.
Almost forgotten! I removed the ‘Is Approved’ property selection from the ‘Create’ form…it’s managed in the later phase.
After this we’ll make sure a task will land in the inbox of your managers. Let’s create a functional role first; That’s a new type of document, saved in the ‘roles’ folders of our project with the name fun_manager:
After publication of the role, you can assign a test user (like my awtest account) to it from the ‘User Manager’ artifact:
You see I also assign the ‘Entity Runtime User’ to my account; Not directly required, but just a good habit to do; Or not? Comment me!
After this user management change, I make sure to use a “Normal” browser tab (with my awdev account) to create new cases in runtime; I use a new “Incognito” tab to evaluate my functionality from a manager role (with my awtest account).
…
Before we can send tasks to an inbox, we first need to apply the ‘Lifecycle’ BB to the ‘Case’ entity. With a simple implementation like this:
Notes:
- Set the ‘Primary transition’ for your happy flow on each flow.
- Get notion of the conditional check; This makes it directly land into the next stage. Not production worthy, but great for a demo.
- We could also trigger an action type of ‘Rule’ starting a BPM that triggers an inbox item (instead of a lifecycle); Just that you know…A task to do on your own! There are always multiple ways to get to the city of Rome.
- Be aware that a lifecycle always starts after creation of the entity instance!
To give the lifecycle a visibility on the entity, I add the ‘Progress Bar’ panel to the default layout for our entity:
Time for a publication and a first lifecycle test in runtime:
I have nothing assigned (yet!) to the ‘Approval’ activity, the task will land in the inbox of the account creating the entity instance; In my case awdev who creates cases. You can check it our yourself as I will continue the craftsmanship.
Next step is to make sure the task lands in the inbox of our ‘Manager’ role (which can be multiple users!). It’s a simple configuration in the ‘Works assignment’ tab of the activity properties:
AND as we’re already in the lifecycle…We’ll also check our case_is_approved property for a correct conditional transition to the next stage:
Can we also build it differently? Yes, we could…Choices, choices! We currently check a condition on a property in the lifecycle transition, but we can also make those ‘Approval’ and ‘Rejection’ transitions of type of ‘User event’ which adds action buttons to the entity instance! ONLY, that requires a different implementation for the ‘Manager’ role as well because this role then needs access to a special “approval” list to open the entity instance and hit approval from there. What I say…Choices, choices!
You can do a publication and do a test, but I can assure you there is no option to approve the case instance (as we removed the option from the ‘Create’ screen…remember!). AND you’ll even get an error from a awtest perspective trying to open the task:
It throws the error because you don’t have any access (security-wise) to the entity instance! So, for this we need to add the ‘Security’ BB to the ‘Case’ entity where we make sure the fun_manager has sufficient privileges:
You see I also add the ‘Identity Administrator’ as a role; This makes sure my
awdevaccount with ‘Developer’ role can still access everything (for this role I checkmark all the options)
You can try it out with a new publication…Trust me 😇, the error is gone which leaves us with a final option to set the case_is_approved property with a REQUIRED value of TRUE|FALSE (as our default NONE option isn’t a valid outcome to continue the flow)! For this we first create a simple frm_approval form on the ‘Case’ entity which exposes only the ‘Is approved’ property (or any other case related information required to make the decision!).
Don’t be smart to make it a ‘Checkbox’ type of input as it has a dramatic impact…Try it out; You’ll find out what’s the reason…Check the answer at the end of this post!
Next, from a lifecycle perspective, we can add a new layout from the ‘Layout model’ tab (see about 4 screenshots back in time!). Only, there is NO layout selectable…That’s because it must be a layout in scope of the related ‘LifecycleTask’ entity. Have a look again in the ‘Case’ entity and see that a new ‘Task list’ BB came available after applying the ‘Lifecycle’ BB. Open this entity from the advanced configuration section:
In the related entity, you can create a new layout lyt_case_task which you configure with the just crafted frm_approval form of the ‘Case’ entity:
I also add the breadcrumb-panel to be flexible in our movement for returning to the overview!
…
Are you still with me? 🤠 I’m just building as we go…I also have a feeling we even get a different result for the intended output of this post, but I’m very curious if it works!
…
In the lifecycle, you can now select the layout which makes the circle complete to do our first test:
Where are you waiting for…Publish, and dive into runtime…
Create a new ‘Case’ instance with awdev which should hold for an approval; This account also can’t do any approval/rejection as it does not have the ‘Manager’ role applied. Now move to the incognito tab with your manager awtest and open (from ‘My inbox’) the “role” type of task and have a look what you see:
We can discuss the “correctness” of the error message, but I leave that discussion out of scope for this post.
Hit one of the two options and double-check the state of the lifecycle with the awdev account with a view of the case instance. Isn’t that magic? Without any task completion (in case you haven’t noticed!). So, what happened with the task? Well, it got obsolete because the lifecycle met the state-change trigger condition to continue to the next phase…Aha! Was it intentionally build like that? Nope to be honest, but it makes things easier for your manager as well! To make the approval choice irreversible, you can add a ‘Rule’ BB to disable the property ‘Is approved’ (via a rule category on the property) once it’s not NONE (which is “not empty”) anymore! I leave this task for you as it’s part of all the extra’s we can implement to extend our MVP for now.
…
Now for our end-conclusion as you see that low-coding can bring you to new unexplored territory which doesn’t even need a new “iPad layout” (which was the intention of the post) as we’re using things out of the box here! We can discuss if it applies to all the requirements, but it does the trick for now…We can indeed improve functionality where needed, but it all depends…as always!
…
ALMOST forgotten…Your managers work on fancy an “iPhone 14 Pro MAX” which looks like this in runtime:
And this will be a choice to make:
After this choice, they can return via the mobile breadcrumb!
That’s what I call a simplicity “DONE”; What I say, the simple doesn’t need to be complex. Can we improve on this implementation? For sure, but always think out of the box and be creative. Don’t fall into the trap of building a rocket before trying out a simple solution first and don’t give your end-users directly your full hand. With smart communication skills and managing expectations, you’ll get further on a steady solution with still a happy user (and customer!). Have fun with these valuable thoughts; We see each-other next week in a new post on AppWorks Tips.
Hereby the answer to the question, why a checkbox wasn’t smart? Well, NOT selecting it will trigger the “isRequired” event with an error!? Don’t shoot the messenger here as we all know that FALSE is also a valid (required) input. ONLY, it depends on how you read it. So, is it a feature or is it a bug…You tell me. Or better…Tell OpenText!
Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?
